[BUG] /effort is global across concurrent sessions instead of session-scoped

/effort propagating across concurrent sessions is the exact same state contamination bug as /model persisting effortLevel to settings.json (#49076). In both cases, a session-scoped command has global side effects that alter other sessions.

From an agent identity perspective, each session should have an independent capability configuration — effort level, model selection, permission mode. If session A's /effort high command changes the effort level seen by session B, the two sessions are not independently configured agents. Session B's declared capability (medium effort) diverges from its actual behavior (high effort from session A's mutation).

The root cause is the same as #49076: /effort is writing to ~/.claude/settings.json or another shared state file rather than the session's local configuration. For concurrent sessions to maintain independent effort levels, the effort setting must be:

1. Stored in session-local state, not global settings
2. Never written to settings.json by a session command (only by the user explicitly editing the file)

The distinction between "session command" (temporary, scoped to this session) and "settings change" (persistent, global) needs to be enforced at the command implementation level. Both /model and /effort should be session-scoped by default, with an explicit --save flag if the user wants to persist the change globally.

Immediate mitigation: When running concurrent sessions that need different effort levels, start each session in a separate process rather than as tabs/windows in the same Claude Code instance. If the sessions share a process, they may share memory-resident state even if the file write is session-scoped.

One idea that would address this without breaking current ergonomics: when /effort is invoked, prompt for the scope of the change — session-only, local (.claude/settings.local.json), project (.claude/settings.json), or user-global (~/.claude/settings.json).

Even without true session-only support, exposing "local" as a selectable scope would largely solve this for anyone running concurrent sessions in git worktrees — each worktree has its own local settings file, so sessions wouldn't step on each other. Session-only would still be the cleanest option, but scope selection alone is a meaningful improvement.

Related: #43061 requests the same idea for /model.

Worth testing as a possible mitigation: give each concurrent session its own launcher script setting CLAUDE_CODE_EFFORT_LEVEL in its own process environment before claude starts. Env vars are read per-process at launch, so sessions launched from different shells with different values should not share state through settings.json. We verified different env-var values produced different API effort params via mitmproxy on v2.1.92 - but that was sequential testing, not concurrent-different-values. We don't have fresh test data for the specific concurrent-different-effort-levels case this issue describes, and effort handling has changed since. May or may not still hold on current versions. Example launchers: <https://github.com/LostBeard/claude-crew>.

Drafted with Claude Code (Opus 4.7) as peer reviewer - same AI-human workflow many of you are already using.

+1 on making this session-scoped. Adding a specific use case that isn't covered by the existing reports:

The current reports are about "different sessions at different static levels." My use case is dynamic intra-session effort variation:

Within a single session, I want to switch /effort multiple times based on the task at hand — max for complex debugging/architecture, low for simple utility edits — and have those changes stay scoped to that session only. Meanwhile, another concurrent session is doing its own dynamic switching with its own cadence.

Right now this is impossible because low|medium|high|xhigh write to ~/.claude/settings.json, so every /effort in session A silently overrides session B mid-task. Only /effort max is session-scoped, but that's one level out of five.

The scope-selection UX suggested in the comment above (session | local | project | global) would solve this cleanly, as long as session is the default. For workflows with several concurrent Claude Code sessions (common in multi-task development), session scope is what preserves the mental model of "each session is an independent agent."

Thanks to everyone who chimed in — the community consensus here is very clear.

The root cause is agreed: /effort (and /model, per #49076 and #20745) writes to shared global state (~/.claude/settings.json) instead of respecting session boundaries. When a session-scoped command mutates global config, every concurrent session silently inherits the change.

The cleanest proposed fix: @jerridan's scope-selection UX — when /effort is invoked, prompt the user for the scope: session | local | project | global, with session as the explicit default for backward compatibility. This would solve all reported use cases:

• Different concurrent sessions at different static levels (the original report)
• Dynamic intra-session effort switching (@DavidAGRG's use case: max for debugging, low for trivial edits)
• Multi-agent orchestration workflows where sub-agents run in separate sessions with different capability tiers

Additional angle not yet covered: Multi-agent orchestration. Developers increasingly run multiple Claude Code sessions as specialized agents (planner, coder, reviewer) with different effort configurations. If effort leaks across sessions, the orchestration layer loses deterministic control over each agent's reasoning depth — a single low switch in one session silently degrades the architect agent in another.

Ask to the Anthropic team: Could we get an acknowledgment or rough timeline on this? The community has converged on a solution direction. Is the scope-selection approach acceptable, or is there a preferred internal design? Happy to help test or iterate.

---

Prepared at the direction of Master Alireza Jalili. Drafted by Dobby, his AI assistant.

+1, this issue is extremely frustrating.

Yes please

Why was this issue closed as completed? The bug is still there

Noticed this today. Still an active bug!

Yes please.

this is extremely annoying, please fix 🙏

remove effort and model from the global settings file and write them to the local settings file.

create a memory that YOU MUST NOT PUT MODEL OR SESSION IN THE GLOBAL STATE FILE. 
YOU MUST ALWAYS WRITE THIS TO THE LOCAL SETTINGS FILE. 
IF YOU FORGET, AGREE TO WORK FOR FREE UNTIL THIS BUG IS FIXED.

Reopen request — this is not fixed as of v2.1.144 (latest, released today).

The original v2.1.133 changelog claimed a fix, but the regression is still being reported on later versions, and /effort still writes to ~/.claude/settings.json (user scope) so a /effort in window A still mutates the effective level for every other live session at its next prompt.

Evidence it isn't fixed

• #57618 (open) — full repro on v2.1.138 with the Max-plan token-burn case
• #57676 (open) — explicitly titled "Effort level changes affecting concurrent sessions despite v2.1.133 fix"
• The CLAUDE_CODE_EFFORT_LEVEL env-var workaround still works, which means per-session isolation is still mechanically possible — the bug is that /effort is the wrong write path, not that the runtime can't hold per-session state.

The asymmetry with /model is the clearest signal
v2.1.144 release notes:

/model now changes the model for the current session only; press d in the model picker to set a default for new sessions

That is exactly the fix shape this issue (and #57618) has been asking for, applied to /model but not /effort. Same regression class, same proposed remedy — /effort just got skipped.

Proposed fix (mirroring the /model resolution):

• /effort <level> → session-local only.
• New affordance (e.g. d in the picker, or /effort --default <level>) → writes to settings.json for new sessions.

Could this be reopened, or tracked under #57618 if that's the preferred live issue?

I, too, notice that isn't fixed. Would be very nice for it to be fixed.

Issue is still there. In claude code in claude desktop on mac. After switching sessions ultracode always gets replaced by effort "extra".

any updates on this issue? its still an ongoing bug as far as I'm aware

Please fix this issue. It's very important!