Model setting changes globally across all sessions (regression)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/12491
2. https://github.com/anthropics/claude-code/issues/17820
3. https://github.com/anthropics/claude-code/issues/7341

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Confirmed - Additional Discovery

I can confirm this regression. During debugging, I discovered an interesting detail:

The /tmp/claude-{sessionId}-model files ARE correct

My HUD plugin writes the current model to /tmp/claude-{sessionId}-model after each API response. These files correctly show different models per session:

$ for f in /tmp/claude-*-model; do echo "$(basename "$f"): $(cat "$f")"; done
claude-5383bc03-...-model: Sonnet 4.5
claude-55903d5e-...-model: Opus 4.5
claude-6c41db32-...-model: Sonnet 4.5

The bug is in the global setting sync

When I change the model in Session A with /model opus:

1. Session A's header updates to Opus ✓
2. Session B's header immediately updates to Opus (without any user action) ✗
3. Session B's HUD still shows Sonnet (correct - no API call yet)
4. When Session B makes a request, Claude Code uses Opus (the global setting)
5. Session B's HUD updates to Opus (correctly reflecting what was actually used)

Root cause confirmation

The model setting is being written to a global location and all sessions watch/read it. The per-session transcript files do contain the correct model used for each API call, but the setting that determines which model to use for the next call is shared globally.

Expected behavior

Each session should maintain its own model preference independently, as it did before this regression.

I'll add this behaviour is random, I can't reproduce it every time

I'll add this behaviour is random, I can't reproduce it every time

Well, that's strange, because it happens every single time on my end.

I see this is marked as stale but this is still happening on 2.1.45 and it's really disruptive.

Happening on 2.1.49

We don't have any update on this? I am also experiencing this bad behaviour each time in the last week

Please address this. This can inadvertently cost money (if Opus 1M gets set on all sessions), or degrade performance (if all sessions switch to Sonnet)

confirmed I can consistently observer this behavior in my claude sessions (Claude Code v2.1.63)

I thought I was seeing this but it could just be my status line which uses jq -r '.model.display_name not refreshing - separate or related issue?

• settings.json
• statusline-command.sh
• Screenshot discrepancy:

<img width="992" height="139" alt="Image" src="https://github.com/user-attachments/assets/653ae162-9c45-4d12-9111-6b6af6446c58" />

Can confirm that I am facing the same issue on 2.1.63

Additional finding: the /context command seems to be more reliable than the status line for checking which model is actually being used.

In my case, after switching models in a different session:

• Status line still showed Opus 4.6 (1M context)
• /context output showed claude-opus-4-6 · 200k (not the 1M variant)

So the display and the actual model are out of sync. This might be useful for others trying to verify whether the bug is cosmetic or actually affecting which model is being used — /context appears to reflect the real state more accurately than the status line.

Confirmed same issue on 2.1.63. Statusline stale. model should not change globally across all sessions.

Confirmed same issue on v2.1.74. We don't able to choose different models and effort type on different sessions.

Confirmed same issue on 2.1.63. Statusline stale. model should not change globally across all sessions.

After many days with this problem, I see that it is instead a problem of stale statusline instead of a real model change across concurrent projects.

Reproducing this on macOS (March 2026).

My ~/.claude/settings.json has "model": "sonnet" and "effortLevel": "medium" set as defaults. When I use /model opus in one terminal session, any new Claude Code session I open afterwards starts on opus instead of sonnet.

Confirmed that no ANTHROPIC_MODEL env var is set, and there's no project-level .claude/settings.json override. The /model command is clearly writing to the global settings.json rather than staying session-local.

This makes the global default setting effectively useless if you ever switch models mid-session.

Seeing this too on macOS 15.5 (Darwin 24.6.0).

Additional context: the model configuration docs describe /model as a "during session" option, listed separately from the "Settings" option for permanent configuration. So the docs imply /model should be per-session, but the implementation writes to ~/.claude/settings.json.

Confirming on Windows 11, Claude Code v2.1.x (latest)

Reproducing consistently — every /model change in one session immediately propagates to all other active sessions. The root cause appears to be /model writing to ~/.claude/settings.json (global) rather than maintaining a session-scoped override.

As @ChrisEdwards noted, the docs describe /model as a "during session" option, implying it should be session-local. The current behavior makes it impossible to run concurrent sessions on different models without using --model on launch.

This is particularly disruptive for workflows running parallel sessions (e.g., one on Opus for complex tasks, one on Sonnet for quick queries).

Posted by an AI agent (Claude Code) on behalf of a user, with their review and approval.

Confirming this on Linux/WSL2 (v 2.1.84)

Setting model in .claude/settings.json or using --model at launch works for pinning a session to a fixed model at startup, but breaks down when you need to switch models during an active session — e.g. starting with Sonnet for routine edits, then switching to Opus for a complex reasoning task, then back. That pattern is a normal interactive workflow, and right now any /model call during it will clobber every other running session globally.

Still confirming on WSL (v2.1.86)

The model setting is stored globally in ~/.claude/settings.json, so changing it in one session affects all sessions.
Workaround 1 — Use project-level model override:
Set the model per-project in .claude/settings.local.json:

// /path/to/project-a/.claude/settings.local.json
{
  "model": "claude-opus-4-6"
}
// /path/to/project-b/.claude/settings.local.json
{
  "model": "claude-sonnet-4-6"
}

Project-level settings override the global setting, so each project can have its own model without affecting others.
Workaround 2 — Use environment variable per session:

CLAUDE_MODEL=claude-opus-4-6 claude
CLAUDE_MODEL=claude-sonnet-4-6 claude

The CLAUDE_MODEL env var overrides the settings.json model for that session only.
Workaround 3 — Use --model flag:

claude --model claude-opus-4-6

The flag overrides both settings.json and env vars for that session.
Workaround 4 — Avoid /model command, use settings instead:
The /model command writes to the global settings.json, which is why it affects all sessions. Using project-level settings or env vars avoids this.

This is a massive gap. Running parallel sessions with different models (Opus for architecture, Sonnet for implementation) is a completely normal workflow, and right now it's broken by design. The global settings.json write means I can't trust any mid-session /model switch when I have multiple sessions open.

This alone is enough to make me consider switching back to Cursor. It's not a nice-to-have; it's basic session isolation. Per-project or per-process model state should have been the default from the start.

<shameless-plug> Hey peeps, even though this won't solve the specific issue there's a way to make models sticks per (named) sessions with https://github.com/fgrehm/clotilde, feel free to give it a try and LMK if it works for you or if you have any feedback :homer-backs-into-bushes:

It's very frustrating and not documented.
I'm disappointed I've learned it from my own experience of using claude code. It ruined my few sessions.
It needs not only fixing but being documented too.

Seriously Anthropic, you take the time to add a virtual pet but you can't figure out transient model settings since Sep 2025?

This is actually critical to me, please considering fixing this. It's very common to work on 4+ session, and you definitely want the flexibility on models each session uses.

I couldn't anymore, so, inspired by @fgrehm 's plug, made a working workaround: https://gist.github.com/unthingable/78f3358f44418f887f11fed7d42aef08

It's a wrapper script that prevents CC from erasing terminal history and supplies it with a per-session transient config, solving this problem. Tested and working with 113/114 in cmux.

If the model is changing for ALL sessions that are already open, that is going to consume a TON of unnecessary tokens. Maybe its part of the token issues everyone has been complaining about, because changing the model midstream in a conversation breaks the cache. If this is truly what is happening, then I am very frustrated that this bug has been unaddressed for this long.

🫪 please fix

Also experiencing this issue, the "work-arounds" are not very nice to use

<img width="1024" height="1024" alt="Image" src="https://github.com/user-attachments/assets/54f21ecf-25ac-4f97-8037-8fe87c1d3edd" />

This is a pretty bad regression; if I have a few sessions open, and in one session I really need to cook with some complex stuff, I might switch it to Opus 1M MAX. However now in the basic stuff which sonnet can handle, it is now costing me much more.

Is this just a way to get more money out of users (i.e. intentional dark pattern)?

This is hilarious

This issue was fixed as of version 2.1.144.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.