[BUG] VS Code extension ignores project and local settings scope for model, and lets user scope override both scopes for effortLevel (Desktop app unaffected)

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?

The VS Code extension does not resolve model and effortLevel according to the documented settings precedence. Two distinct symptoms, both in new-session initialization:

1. effortLevel — user scope outranks project and local scope.
Precedence among the project files works correctly: .claude/settings.local.json beats .claude/settings.json, and removing a key from local correctly falls through to project. But as soon as ~/.claude/settings.json contains an effortLevel, it wins over both. That is the inverse of the documented order.

2. model — project and local scope appear to be ignored entirely.
With model set in .claude/settings.json and .claude/settings.local.json and no user-scope file present, new sessions start on the organization default instead of either configured value. Neither project file has any effect. When a user-scope model is present, that value is used — so user scope is honored while the two higher-priority scopes are not.

The organization default does not appear to be a managed policy: a user-scope model overrides it, which a managed setting would not permit.

The same tests run against the Claude Code Desktop app on Windows, with the same files, behave correctly — precedence is respected, and the app does not rewrite user scope when the model or effort is changed in a session.

What Should Happen?

New sessions should resolve model and effortLevel from the highest-priority scope that defines them:

1. Managed settings
2. CLI flags
3. .claude/settings.local.json
4. .claude/settings.json
5. ~/.claude/settings.json

A project that pins "model": "sonnet" and "effortLevel": "medium" in its version-controlled .claude/settings.json should start on Sonnet at medium effort, regardless of what an individual developer has in their own user-scope file — and either value set in .claude/settings.local.json should override the project file in turn.

Error Messages/Logs

No error is produced. Settings are silently resolved from the wrong scope, with no warning and no indication in the session header that a lower-priority file has overridden a higher-priority one.

Steps to Reproduce

CLAUDE_CODE_EFFORT_LEVEL and ANTHROPIC_MODEL unset. No CLI flags. No managed settings present — /etc/claude-code/ does not exist on the test machine.

Test 1 — effortLevel: project-scope precedence works; user scope overrides it

Project files:

// .claude/settings.json        (project)
{ "model": "opus", "effortLevel": "low" }

// .claude/settings.local.json  (project-local)
{ "model": "fable", "effortLevel": "high" }

With ~/.claude/settings.json deleted, and without touching the model or effort controls in any session:

| Change made | New session effort | Correct? |
|---|---|---|
| (as above, local = high) | high | yes — local beats project |
| local changed to medium | medium | yes |
| effort key removed from local | low | yes — falls through to project |
| project changed to xhigh | xhigh | yes |

So precedence between the two project files is correct, and both files are being read.

Now, in a new session, select a different effort using the extension's effort control. ~/.claude/settings.json is created on disk with that value. Open another new session: it starts at the user-scope value, not xhigh from the project files.

Test 2 — model: project and local scope have no effect

Same two project files as above (opus in project, fable in local), user-scope file deleted, model control untouched.

• Observed: every new session starts on the organization default (Sonnet).
• Expected: fable, from project-local scope.

Neither opus nor fable is ever applied. This holds across all the effort variations in Test 1 — the effort value tracked the project files correctly while the model never did.

Test 3 — deleting the user-scope file is not a workaround

1. Delete ~/.claude/settings.json.
2. Open a new session, select Opus and/or a different effort.
3. The file is recreated with those values.
4. Open a new session: it starts on the recreated user-scope values, overriding the project files again.

New-session routes

All of the above was retried by three routes, with identical results each time: relaunching VS Code entirely, closing and reopening only the extension panel, and starting a new session with nothing closed.

Control — Claude Code Desktop app

Same files, same values, Windows. New sessions resolve according to the documented precedence, and changing model or effort in a session does not write to ~/.claude/settings.json. Does not reproduce.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

Unknown — not bisected. See Additional Information: earlier reports describe a different failure mode, which may indicate the behavior changed at some point, but I cannot name a working version.

Claude Code Version

VS Code extension: 2.1.250 VS Code: 1.135.0

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Models involved. With no user-scope file present, sessions resolved to the organization default (Sonnet), ignoring the model values set in project and project-local scope. With a model in ~/.claude/settings.json, that value is used instead — it overrides the organization default, while the project and project-local values continue to have no effect. Values used as configured across the runs: sonnet, opus, fable, haiku.

Subscription. Enterprise. The "organization default" referred to above is the org-level model default, not a managed policy — a user-scope model overrides it, which a managed setting would not permit.

Environment detail. The dropdowns above don't have options that fit this setup, so the detail is here. Operating system: RHEL-based Linux, x64 — selected "Other Linux". The full test suite above was run there. The same scenario was spot-checked on Windows 11 Pro with the same extension and showed the same behavior, though I did not repeat the full matrix, so I can't rule out platform-specific differences in detail. It does not reproduce in the Claude Code Desktop app on Windows 11 Pro — that app respects the documented precedence and does not rewrite user scope when the model or effort is changed in a session.

Interface. Sessions run in the Claude Code VS Code extension panel — not the claude CLI inside a terminal. I selected "Other" for Terminal/Shell since no option covers the extension panel; the integrated-terminal option would suggest the CLI, which is a different code path and, as far as I can tell, resolves precedence correctly. Shells otherwise in use on these machines: bash / tcsh (Linux), Git Bash (Windows).

Existing sessions are correctly isolated. A session previously set to a given model and effort reopens with those values regardless of what user scope currently holds. Per-session state is persisted and scoped correctly, which narrows the fault to new-session initialization rather than state persistence generally — the extension already has machinery to hold a per-session value that user scope does not clobber.

That said, changing the model or effort inside a pre-existing session also writes to ~/.claude/settings.json, and the next new session starts from those values. Every route to changing the setting feeds the file that subsequently overrides project configuration.

A possibly relevant asymmetry. /config in the extension exposes a model key (default|sonnet|opus|haiku|fable|best|sonnet[1m]|opus[1m]|fable[1m]|opusplan) but no effort key at all. That mirrors the split in symptoms above — effort reads the project files correctly while model never does — and suggests the two settings take different resolution paths in the extension. Noting it as an observation, not a diagnosis. (/status is also unavailable in the extension, so I could not use it to confirm which settings sources were in effect.)

Scope of this report. The extension writing interactive selections to ~/.claude/settings.json is already reported (#53331, #57618) and is not what I am reporting. I describe it only because it explains how user scope acquires values in normal use, and why the symptoms can't be worked around independently. If precedence were fixed, the write behavior would be harmless — the project setting would win and user scope wouldn't matter.

There is no workaround. Deleting the user-scope file doesn't help (Test 3). The only mechanism that reliably overrides user scope is CLAUDE_CODE_EFFORT_LEVEL, which pins the value and disables the effort control for the session, and which has no equivalent for model without the same trade-off.

Practical impact. Version-controlled per-project configuration is unreliable for teams using the extension. Our case: a shared codebase where we want Sonnet as the team default and effort tuned per project. model cannot be pinned per project at all, and a developer's one-off switch to Opus becomes their persistent default across every project. Avoiding wasted spend depends on each developer remembering to check the model at the start of every session — which is what the project-scope setting exists to prevent.

Relationship to earlier reports. Two earlier issues describe a related but different failure mode:

• #39133 (Mar 2026) — effortLevel set in all three files, session always starts at medium; all scopes ignored.
• #45877 (Apr 2026) — the extension ignores ~/.claude/settings.json and CLAUDE_CODE_EFFORT_LEVEL entirely; the CLI honors both.

Both describe the extension ignoring user scope. For effortLevel I observe the opposite: user scope is read and given top priority. If those reports were accurate when filed, the resolution logic has changed since. Both were closed as duplicate with no linked parent issue and no assignee, so there is no active thread to add this to.

If this is judged a duplicate, a link to the canonical issue would be appreciated — none of the related issues currently has one.