[BUG] VS Code extension drops Auto from the mode picker when user-settings model is an alias absent from the models list (e.g. "opus") — availability stuck at "unknown"

Status Open

Reported on v2.1.251

Maintainer reply None cached

Activity 0 comments · opened Aug 29, 2026

Edited 2026-08-29: the original report blamed a regression in 2.1.251. That was wrong — further tracing shows the same code in 2.1.250 and 2.1.251, and the real trigger is a startup race combined with a user-settings model alias that the webview cannot resolve. Title, description and repro rewritten accordingly; the regression label no longer applies.

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?

Symptom, precisely: a conversation starts in Auto (account default), and Auto is listed in the picker only while the conversation is in Auto. Switch to Manual (or Edit automatically / Plan) and open the picker again: Auto is gone and cannot be selected again. Same in resumed and brand-new conversations. Conversations resumed in acceptEdits (last picked mode) therefore never show Auto at all — which is how it first looked like "Auto disappeared".

The bundled CLI approves auto mode for the same session:

[auto-mode] verifyAutoModeGateAccess: enabledState=enabled disabledBySettings=false model=claude-sonnet-5 modelSupported=true carouselAvailable=true canEnterAuto=true

and claude -p ... --output-format stream-json from the same binary starts with "permissionMode":"auto".

Root cause (traced in webview/index.js and extension.js; 2.1.250 and 2.1.251 behave the same):

The picker adds auto when autoModeAvailability === "available", or when it is "unknown" and the current mode is already auto — which is exactly the observed "only while in Auto" behaviour. "unknown" is returned when currentModelInfo is undefined.
currentModelInfo looks modelSelection up in claudeConfig.models by value / resolvedModel.
modelSelection is set once per conversation, at launch, from config.modelSetting, which the host computes as cachedClaudeSettings?.effective?.model ?? cachedUserSettings?.model ?? "default".
cachedClaudeSettings is only populated after the config probe (Loading config cache by launching Claude (no channel)..., several seconds). A conversation launched before that falls back to cachedUserSettings.model, i.e. the raw model value from ~/.claude/settings.json.
For this account the initialize response lists models as default (→ claude-opus-5[1m]), opus[1m], claude-fable-5[1m], sonnet, haiku. There is no plain opus entry, while the CLI itself resolves --model opus to claude-opus-5. With "model": "opus" in user settings the lookup fails → "unknown" for the whole life of that conversation.

There is also a benign, transient form of the same state: right after the window opens, before the config (models list) reaches the webview, opening the picker shows no Auto; a few seconds later (once the "Remote Control is active" banner appears) it does. With an unresolvable alias the state never recovers.

What Should Happen?

Auto should be listed whenever the CLI reports canEnterAuto=true, regardless of the current mode. Concretely: resolve model aliases the way the CLI does (opus, sonnet, haiku, ...), or don't key modelSelection on the raw user-settings value before effective settings are known, and don't leave availability at "unknown" once the gate and the disable checks have passed.

Error Messages/Logs

Controlled A-B-A on the same machine, extension 2.1.251, project `.claude/settings.local.json` pins `sonnet`, only `~/.claude/settings.json` `model` changed; after each change: Developer: Reload Window, wait 20 s, then in both the resumed and a new conversation switch Auto → Manual and open the picker:

| user-settings `model` | in models list? | Auto after leaving Auto |
|---|---|---|
| "opus[1m]" | yes | listed (resumed and new) |
| "opus" | no | gone (resumed and new) |
| "opus[1m]" | yes | listed (resumed and new) |

Extension output log (%APPDATA%\Code\logs\<session>\window1\exthost\Anthropic.claude-code\Claude VSCode.log), a failing session:

09:58:56.698 Received message from webview: {"type":"get_claude_state"}
09:58:57.409 Loading config cache by launching Claude (no channel)...
09:59:00.181 Received message from webview: {"type":"launch_claude", ..., "resume":"<id>", "permissionMode":"acceptEdits"}   <- launched before the probe finished
09:59:06.546 From claude: [auto-mode] verifyAutoModeGateAccess: enabledState=enabled disabledBySettings=false model=claude-sonnet-5 modelSupported=true disableFastModeBreakerFires=false carouselAvailable=true canEnterAuto=true

`initialize` control response (models), bundled binary 2.1.250 and 2.1.251, this account:
{"value":"default","resolvedModel":"claude-opus-5[1m]","supportsAutoMode":true}
{"value":"opus[1m]","resolvedModel":"claude-opus-5[1m]","supportsAutoMode":true}
{"value":"claude-fable-5[1m]","resolvedModel":"claude-fable-5","supportsAutoMode":true}
{"value":"sonnet","resolvedModel":"claude-sonnet-5","supportsAutoMode":true}
{"value":"haiku","resolvedModel":"claude-haiku-4-5-20251001"}

`get_settings` → effective.model = "sonnet" (project-local); sources[userSettings].model = "opus".
`claude -p --model opus` → init.model = claude-opus-5; `--model default` → claude-opus-5[1m].

Steps to Reproduce

Claude Max account, Anthropic API, Windows, VS Code extension 2.1.251 (2.1.250 behaves the same). Put "model": "opus" in ~/.claude/settings.json (the account's models list has opus[1m] but no opus).
Developer: Reload Window; the last conversation is resumed within ~3 s, i.e. before Loading config cache... completes.
The conversation starts in Auto. Switch to Manual, open the picker: Manual / Edit automatically / Plan only — Auto cannot be re-selected. Same in a new conversation. Output log still shows canEnterAuto=true.
Control: change user settings model to "opus[1m]" (or "default", "sonnet"), reload, repeat step 3 → Auto stays listed after switching to Manual, in both conversations. Switch back to "opus" → gone again.

Claude Model

Sonnet (default)

Is this a regression?

I don't know — not version-related (see steps: same build shows Auto or not depending on launch timing and the user-settings model value)

Last Working Version

Not version-related (A-B-A above on a single build). First noticed 2026-08-29.

Claude Code Version

Extension 2.1.251 (bundled native claude.exe 2.1.251); also reproduced on 2.1.250; VS Code 1.135.0; Windows 11 Pro 10.0.26200.9168

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Claude Desktop app (Code tab), same account: Auto is offered normally (it doesn't share this lookup).
Earlier reports with the same symptom and the same canEnterAuto=true contradiction, all closed without a documented cause: #60086 (2.1.143), #44941 (2.1.94, Windows), #61282 (2.1.145, Linux). The mechanism above would explain them whenever the reporter's user-settings model was an alias not present in their account's models list.
Workaround: set user-settings model to a value that exists in the models list (opus[1m], default, sonnet).

View original on GitHub ↗