[BUG]: Tab agent switch: first message after the switch still runs on the previous agent's system prompt

[mewmewmemw]

Description

On v1.18.15, switching between custom primary agents with Tab in a live session records the new agent correctly, but the first user turn after the switch still runs on the previous agent's system prompt.

Expected: The first message after a Tab switch uses the new agent's system prompt.

Actual: The first user turn after the switch runs on the previous agent's system prompt. The model self-identifies as the previous agent and follows its prompt rules, while the message metadata (data.agent/data.mode) and the server log (message=stream agent=<new agent>) both record the new agent. The turn after that (next user message, no switching at all) picks up the correct agent's prompt.

Evidence — observed twice out of 11 switches, in both directions, across two agent pairs:

• In its reasoning, the model quotes the previous agent's system prompt verbatim. In one case it quoted a revision of our prompt that no longer existed in opencode.json at that time (verified against git history and backups), and the conversation history contains no prompt text at all — so the text could only come from the request's system prompt.
• Always exactly the first user turn after the switch.
• No errors or warnings in the server log around the event.

Related: #8946 (stale agent state when returning to a session). Suspected spot: agent resolution in createUserMessage (packages/opencode/src/session/prompt.ts) — the first processing loop after the switch may use the pre-switch agent state; the system prompt itself is built per call from agent.info.system (packages/core/src/session/runner/llm.ts).

Side note: nothing in the stored data records which agent's system prompt was actually sent (step-start carries no agent snapshot), so this class of bug is invisible without reasoning traces — worth logging at generation time.

Plugins

none

OpenCode version

1.18.15

Steps to reproduce

1. Define two custom primary agents (mode: "primary") in opencode.json with distinctly different system prompts; include a self-identification line in each prompt (e.g. "you are agent , announce it in your first reply") so the active prompt is observable.
2. Start a session with agent A and converse for a few turns.
3. Press Tab to switch to agent B and send a message.
4. Occasionally (2 of 11 in our setup): the reply follows agent A's prompt (self-identifies as A) while the message metadata says agent=B.
5. Send one more message — agent B's prompt is picked up starting from the next turn.

Screenshot and/or share link

Session DB extracts (message metadata + reasoning quotes for both incidents) available on request; can provide a /share link of an affected session.

Operating System

macOS 15.6

Terminal

kitty

[mewmewmemw]

Update: root cause identified, fix proposed in #41396.

Root cause — in createUserMessage (packages/opencode/src/session/prompt.ts), when input.agent is absent (the V2 prompt flow does not pass an agent), the agent was resolved via agents.defaultInfo() — the configured default — ignoring the session's selected agent (session.agent). The system prompt was then built from the default agent, producing exactly the reported symptom: message metadata records the new agent while the LLM request carries the previous agent's system prompt.

Additionally, the setAgentModel block in the same function rolls session.agent back to the default whenever the two differ, so the stale prompt can persist across multiple consecutive turns. Observed live once more after filing: 4+ consecutive turns on the stale prompt, cleared only by a process restart — consistent with the rollback mechanism above.

Fix — resolve the agent as input.agent → session.agent → default (degrading to the default only when session.agent points to a removed agent): #41396. Includes an offline regression test that reproduces the bug deterministically (red before the fix, green after).

[mewmewmemw]

Follow-up to my comment above: after building a binary with the first fix, the live symptom reproduced again, revealing a second, deeper mechanism.

Second mechanism — the prompt loop (packages/opencode/src/session/prompt.ts) built the turn's system prompt from the agent stamped on the latest user message, not from the live session.agent. Messages authored before a switch keep the old stamp, so turns kept running on the previous agent — this is what explains the multi-turn persistence reported in this issue (observed live: 4+ consecutive turns on the stale prompt, cleared only by a process restart). The V2 runner is not affected: it re-reads session.agent fresh on every turn.

#41396 now contains both fixes:

1. 16a1511c97 — resolve the agent from session state in createUserMessage (as described above)
2. 4ebf96aa3f — read the turn's agent from the live session state in the loop, instead of the message stamp

Each fix has an offline regression test (in-process TestLLMServer); the second test exercises the real durable AgentSwitched path and fails without the fix. Verified live: Tab switching now applies the new agent's system prompt starting from the very first turn.

[mewmewmemw]

Follow-up from live validation on a local build containing both fixes from #41396 — this bug class appears to have a second layer that the delivery fix does not cover.

Layer A (delivery) — validated live. On a binary built from #41396 (16a1511c + 4ebf96aa), the original defect no longer reproduces: on Tab-switch, message stamps, session.agent, server log, and the wire prefix all switch to the new agent immediately and correctly.

Layer B (behavioral lock) — relapse observed. After an interview → plan agent switch, the model played the old role for 5 consecutive turns despite correct delivery. Root cause: the previous agent's reasoning parts remain in context (toModelMessagesEffect includes them as reasoning, or demotes to text on model change) and they paraphrase the old agent's system prompt — in our case including our own workaround protocol text. Token balance was ~2k new prompt vs ~20k old-role context; an ambiguous first post-switch message pattern-matched the historical scenario. Each stale turn deepened the lock; history is durable in the DB, so a TUI restart did not help.

Key measurement: we added request-level tracing (sha256 + prefix of the final system string in prepare()). In a controlled A/B/C headless experiment, the system-prompt hash and cache.read reset changed at exactly the switch turn in all three runs — including the control that still locked. So a correct delivery / prefix rebuild is necessary but not sufficient.

Experimental fix (local fork), validated: agent-switch-aware context assembly in toModelMessagesEffect, env-flagged, off by default:

• strip-reasoning — drop reasoning parts authored by a different agent (msg.info.agent is stamped on every message);
• boundary — inject one synthetic "agent switched" text part before the first message of the new agent.

Results: both modes produced a clean first post-switch turn (correct role, anchor cited, protocol followed); the control run (no surgery, identical delivery) reproduced the full role lock. Happy to open a PR for either mode if this direction is acceptable upstream.