/new does not clear per-agent model override within TUI session lifetime

[drsmile1001]

Description

Two different flows write to modelStore.model[agentName] (a per-agent, in-memory model override in the TUI):

• User manually selects a model via the model dialog (dialog-model.tsx calls local.model.set()).
• Session loads and restores the last user message model (prompt/index.tsx calls local.model.set(msg.model) when sessionID changes, line 401).

The second flow fires automatically when navigating into a session — no prompt submission needed. Once set, this override persists for the rest of the TUI process. /new does not clear it.

Scope issue: The session model restoration (per-session intent) writes to a global in-memory key (modelStore.model[agentName], keyed by agent name, not session ID). There is no cleanup path when the session ends.

This means that within one TUI process lifetime, after visiting a session:

• client.global.config.update() writes to opencode.json correctly
• But the model indicator continues to show the stale override
• Only a TUI restart restores the baseline (because modelStore.model is not persisted to disk — only recent/favorite/variant are saved in model.json)

Steps to reproduce

1. Start TUI on home page.
2. Call client.global.config.update() with a different model — model indicator updates correctly.
3. Enter a session (messages load, override is set from the last user message's model).
4. /new to return to home.
5. Call client.global.config.update() again with a different model — opencode.json is written, model indicator unchanged.
6. Restart the TUI — the change from step 5 is now visible.

Suggested fix

Clear modelStore.model[agentName] on /new or session navigation back to home. This lets the lookup chain fall through to the refreshed opencode.json baseline, which is necessary for client.global.config.update() (a public API) to always be effective.

Plugins

Custom TUI plugin calling client.global.config.update()

[github-actions]

This issue might be a duplicate of or closely related to existing issues. Please check:

• TUI: User selected agent/model is overwritten by server defaults when creating a new session #7948: TUI: User selected agent/model is overwritten by server defaults when creating a new session — this also involves the same createEffect in prompt/index.tsx that calls local.model.set(msg.model) when sessionID changes, which is the same root area described here.

[drsmile1001]

Reviewed related issues and they all converge on the same mechanism.

Common root cause: The createEffect in prompt/index.tsx (line 384-406) restores the model from the last user message whenever a session is loaded. It writes to modelStore.model[agentName] — a global in-memory store keyed by agent name. There is no cleanup when leaving the session.

Related issues:

• ACP loadSessionMode doesn't restore persisted model/agent from session messages #7804 (closed): The original reason this mechanism exists. ACP did not restore model/agent from session messages, so the TUI added its own restoration layer.
• TUI: User selected agent/model is overwritten by server defaults when creating a new session #7948 (auto-closed): The same createEffect has a race condition where it can overwrite the user's initial model selection on a newly created session. Never actually fixed, auto-closed due to inactivity.
• Feature Request: Retain current model and agent selection when switching sessions #4930 (open): Requests that the user's current model selection persist when switching between sessions — meaning session history should not override the user's active choice. This aligns with our issue: the restore mechanism should not permanently pin the model against the user's (or a plugin's) intent.

The current design has a scope mismatch: session model restoration (per-session intent, reasonable for resuming work) writes to a key that is global and has no expiration. Once set, it shadows opencode.json changes from client.global.config.update() for the rest of the TUI process.

Two possible approaches (either would resolve this):

1. Fix the scope: Clear the per-agent override on /new / session close. The lookup chain then falls through to the refreshed baseline. This preserves the session restoration behavior while preventing it from outliving the session.

2. Add a new HTTP API for session model: The server-side logic already exists in the ACP layer (unstable_setSessionModel, setSessionConfigOption) but is only accessible via the ACP WebSocket. Exposing a simple PATCH /session/{sessionID}/model endpoint would let plugins (and scripts) set the current session model directly, without depending on the config file path. This does not conflict with any of the above issues — it is a complementary capability.