Agent switch fails to append message after 1.17.7 upgrade due to session_message.seq NOT NULL constraint #32670

Summary

After upgrading to opencode 1.17.7, switching agents in an existing session, for example between plan and build, can break the session. After the switch, submitting the next prompt fails and the only workaround is to create a new session.

The server log shows SQLiteError: NOT NULL constraint failed: session_message.seq while appending the agent-switched session message.

Environment

• opencode version: 1.17.7
• Platform: macOS / darwin
• Install path: local opencode CLI binary
• Database: local SQLite database at the default opencode data directory

Steps to reproduce

1. Start opencode 1.17.7.
2. Open or create a session.
3. Switch the active agent, for example from plan to build or from build to plan.
4. Try to submit another prompt in the same session.

Expected behavior

The agent switch should be recorded successfully and the user should be able to continue submitting prompts in the same session.

Actual behavior

The prompt submission fails. The session becomes effectively unusable until a new session is created.

Relevant log

INFO  2026-06-17T09:40:48 +3ms service=skill count=30 init
ERROR 2026-06-17T09:41:29 +41575ms service=server ref=err_2b53db68 error=NOT NULL constraint failed: session_message.seq cause=SQLiteError: NOT NULL constraint failed: session_message.seq
    at run (unknown)
    at #run (bun:sqlite:185:20)
    at appendMessage (/$bunfs/root/chunk-9re0szbd.js:2:62522)
    at session.next.agent.switched (/$bunfs/root/chunk-9re0szbd.js:2:56643)
    at pC (/$bunfs/root/chunk-9re0szbd.js:2:56588)
    at tn (/$bunfs/root/chunk-9re0szbd.js:2:62564)
    at <anonymous> (/$bunfs/root/chunk-9re0szbd.js:2:62753)
    at <anonymous> (/$bunfs/root/chunk-6e52cs3m.js:39:7317)
    at rc (/$bunfs/root/chunk-1n6f171v.js:716:34488)
    at T6 (/$bunfs/root/chunk-6e52cs3m.js:39:7306)
    at <anonymous> (/$bunfs/root/chunk-6e52cs3m.js:39:5669)
    at run (node:async_hooks:62:22)
    at SyncEvent.run (/$bunfs/root/chunk-r2qbym69.js:10:41578)
    at SyncEvent.run (definition) (/$bunfs/root/chunk-6e52cs3m.js:39:5213)
    at SessionPrompt.createUserMessage (/$bunfs/root/chunk-r2qbym69.js:1678:366)
    at SessionPrompt.createUserMessage (definition) (/$bunfs/root/chunk-r2qbym69.js:1677:2012)
    at SessionPrompt.prompt (/$bunfs/root/chunk-9re0szbd.js:80:79399)
    at SessionPrompt.prompt (definition) (/$bunfs/root/chunk-r2qbym69.js:1678:250)
    at SessionHttpApi.prompt (/$bunfs/root/chunk-9re0szbd.js:2:92075)
    at SessionHttpApi.prompt (definition) (/$bunfs/root/chunk-9re0szbd.js:80:79311) failed

There are also MCP messages like Method not found failed to get prompts, but those appear to be unrelated startup noise. The failure that prevents prompt submission is the SQLite constraint error above.

Local investigation

The local session_message table schema contains a non-null seq column:

CREATE TABLE `session_message` (
  `id` text PRIMARY KEY,
  `session_id` text NOT NULL,
  `type` text NOT NULL,
  `time_created` integer NOT NULL,
  `time_updated` integer NOT NULL,
  `data` text NOT NULL,
  `seq` integer NOT NULL,
  CONSTRAINT `fk_session_message_session_id_session_id_fk`
    FOREIGN KEY (`session_id`) REFERENCES `session`(`id`) ON DELETE CASCADE
);

Existing rows for agent-switched and model-switched messages do have sequence values, but the failing stack suggests the session.next.agent.switched append path is attempting to insert a session message without setting seq after the 1.17.7 database/schema change.

Suspected cause

This looks like a regression introduced by the migration/schema change that made session_message.seq mandatory, while the agent-switched event append path still creates a message without assigning seq.

A likely fix would be to make sure appendMessage or the session.next.agent.switched handler assigns the next session-local seq consistently for agent-switched messages, the same way normal user/assistant messages and other session messages are handled.

Workaround

Creating a new session avoids the broken session, but switching agents again can reproduce the issue. Avoiding agent switches in an existing session also avoids the immediate failure.