fix(tui): respect current model config when continuing a session

[st3fk3]

Issue for this PR

• Closes: [BUG]: Model from previous session overrides current config when continuing a session #26351
• Relates to: Only current selected agent's model persists when resuming a session (other agent(s) revert to default) #23369

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Continuing an old session restores the model from the last user message, overriding the current agent config. After changing models between sessions, the old model is still sent to the API.

This removes the model/variant restoration from the session-switch effect. After the fix:

• the config model is always used when continuing a session
• the agent is still restored from session history (intentional)
• /models manual picks still work (they write directly to the model store)

How did you verify your code works?

• built from source and confirmed the correct model is used after changing config and continuing a session
• verified /models picks still override correctly
• checked that subagents are unaffected (they read from agent state, not the model store)

Screenshots / recordings

No UI change.

Checklist

• I have tested my changes locally, see: #comment-4407725787
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found one potentially related PR:

Related PR:

• feat: toggle to keep model/agent when switching sessions #24508 - feat: toggle to keep model/agent when switching sessions (feat: toggle to keep model/agent when switching sessions #24508)
  • This PR is related because it addresses session switching behavior with respect to model/agent state. PR fix(tui): respect current model config when continuing a session #26355 fixes a bug where the old model is restored when continuing a session, while feat: toggle to keep model/agent when switching sessions #24508 adds a toggle feature for this behavior.

Note: The search results show PR #26355 (the current PR) in multiple results, which is expected. The related PR #24508 appears relevant as it deals with the same concern of model/agent state during session transitions.

No exact duplicate PRs found. The issue #26351 (mentioned in the PR description as "Closes") is the specific bug being addressed by this PR.

[st3fk3]

How the fix was verified

Tested by adding a temporary log at the patch site, running against an isolated opencode instance.

Debug snippet:

if (msg.model) {
  Bun.write("/tmp/opencode-session-restore-test.log",
    `[session-restore] skipping model restore: ${JSON.stringify(msg.model)}\n`
  ).catch(() => {})
  // local.model.set(msg.model)
  // local.model.variant.set(msg.model.variant)
}

Before (original code -- restores model from session):

1. Started session with deepseek-chat, sent a message, quit
2. Changed config to deepseek-reasoner
3. Continued session -- old model (deepseek-chat) was restored, config change ignored

After (patched code -- skips model restore):

Same steps. Log confirmed the skip:

[session-restore] skipping model restore: {"providerID":"deepseek","modelID":"deepseek-chat"}

Config model (deepseek-reasoner) correctly took precedence over session history.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.