[BUG] In VSCode extension, is model switching via /model isolated per chat session? Seems like it might not be.
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
This impacts multi-agent workflows where different models are used for different roles (e.g., Opus for audit, Sonnet for implementation).
This issue is really a question or questions about current behavior. Its bug status depends on the answer(s).
- Using VSCode Claude Code extension
- Two chat windows open simultaneously
- Window A set to Opus
- Window B changed to Sonnet via
/model /modelin Window A still reports Opus- But behavior suggests it may actually be using Sonnet (possible mismatch), and it reports itself as Sonnet instead of Opus
Concern:
- Model selection might be shared/global rather than per-session
- Does selecting a new model in chat B also change it silently for chat A?
- what is shown by
/modelin a chat window may be stale or misleading if it is changed in another chat window - if the /model changes silently in chat A, it definitely is not reflected when looking at the GUI to see what model and Effort are selected
What Should Happen?
Expected:
- Model selection should be clearly scoped (per chat vs global)
- Selecting a model in one chat should never affect the model being used in another
/modelshould reflect actual execution model, not cached state
Impact:
- Difficult to trust model behavior during multi-window workflows
I understand that this may not be a bug. So please interpret it as a clarifying question that was motivated by thinking it might be acting like this, which would certainly be something to fix.
Thank you for your time and patience, and the great tool
Error Messages/Logs
Steps to Reproduce
- Open VSCode
- Open VSCode Claude Code extension chat
- Window A: Select Opus with Extra High Effort (or any model with any effort)
- Window A: Do some work with it
- Window B: Open a new chat to work in parallel
- Window B: Select a different model and effort; for example, Sonnet with High Effort.
- Window B: Do some work with it
- Go back to Window A to prompt some more work
- Did the model in Window A change? (for example to Sonnet with High Effort)?
- If so, the model and effort reported are incorrect.
Performance changes in Window A after the model change in Window B made me concerned about this. I apologize if the concern is not justified.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.112 (Claude Code)
Platform
Other
Operating System
macOS
Terminal/Shell
VS Code integrated terminal
Additional Information
I am not using Terminal actually. Just the VSCode extension.
Showing cached comments. Read the full discussion on GitHub ↗
9 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Great question about multi-agent workflow isolation — this trips people up a lot.
From my testing:
/modelin Claude Code VSCode is per-window session, not global. If Window B switches to Sonnet, Window A stays on Opus — but there's a known race condition where global config updates can briefly leak across sessions.The "behavior suggests otherwise" part: if you're seeing bleed-through, check if both windows share the same
~/.claude/settings.json— there's a brief window where the file write from one session can be read by another before it gets the in-memory value.For multi-agent workflows with different models per role, the reliable pattern is: don't use
/modelswitching mid-session. Instead, configure per-context inCLAUDE.mdor use separate workspaces with different.claude/settings.jsonconfigs. This keeps the model assignment deterministic across your fleet.If you want a systematic approach to multi-agent Claude Code setup (role assignment, context isolation, memory management), I wrote up a skill for it: https://clawhub.ai/@abhinas90/multi-agent-deployment-pro
No, it is definitely global in VSCode still to this day. If you have Opus in a chat and you go open a new chat and switch to Sonnet, you better believe the thing you think is Opus is now Sonnet. Easiest tell is the context window becomes much smaller. It also begins self identifying as Sonnet (something Opus never does in my experience until the switch happens and its no longer Opus), and even if your chat session is days old, it will all of a sudden think the chat session just started.
This persists as a problem.
Worse --> when you switch models, all chats you do have open automatically restart and destroy your session usage limit, similar to another massive bug that needs to be fixed I described here: https://github.com/anthropics/claude-code/issues/55046
Oh and yes -- this is when working in the same repo. That is an important fact relevant to what you pointed out about
.claude/settings.jsoninside the repo. However, that file has no mention of the model for me. It is very small. It can be erased without obvious effect too.So yes, let's make this problem better defined. It may not be limited to this, but the bug I described is for working in the same repo in VSCode with more than one Claude Code chat for role switching and/or parallel tasks, etc.
I have also encountered this problem and would like it to be addressed.
Confirmed on macOS with the latest VS Code extension. "Switch model..." via the
/command menu changes the model globally across all open VS Code sessions, not per-session. The terminal CLI does support session-scoped switching; the extension lacks an equivalent.Tested this systematically on Linux, VS Code extension v2.1.204 (latest as of 2026-07-08), and I can add a data point that narrows the bug down: it's UI-only in my case — the runtime is correctly isolated per session.
Method: the session transcripts under
~/.claude/projects/<project>/<session-id>.jsonlrecord the actualmodelthat served each assistant message, so you can verify the real serving model per window instead of trusting the UI.Controlled experiment, two windows in the same workspace:
/model.claude-fable-5, Window B still served byclaude-opus-4-8— no bleed-through at the runtime level.However, the "Switch model…" entry in the
/command menu shows the same (last-selected) model in both windows, so the UI misreports the per-session state. That alone is bad: you can't trust the menu to know what model a given window is on, and it may explain why this reads as a global switch. Checking the transcript'smodelfield is the reliable way to tell which case you're hitting.Correction/update to my comment above: the UI mislabel I reported was almost certainly observed on v2.1.202 — the extension had auto-updated to 2.1.204 that morning, but my already-open windows were still running the old version until reloaded.
As of now, on v2.1.204, I can no longer reproduce it: after switching one window to Fable via
/model, the other window's "Switch model…" menu correctly keeps showing its own model (Opus). Transcripts confirm each window serves its own model, as before.Caveat: I find no changelog entry for this in 2.1.203/2.1.204 (closest is 2.1.193's "client-data-gated UI stale after
/login" fix, which was already present in my buggy 2.1.202). So either it was fixed silently, or the stale menu label simply resets on window reload and would reappear in long-lived windows. If anyone still hits it: check your running extension version (an open window keeps executing the pre-update version) and verify the actual serving model via the transcriptmodelfield as described above.