VS Code panel silently drops Auto from the permission-mode picker while the extension host reports canEnterAuto=true

Summary

In the VS Code panel, the permission-mode picker silently dropped Auto, showing only 3 modes (Manual, Edit automatically, Plan). Shift+Tab cycled 3 stops and wrapped Plan → Manual. Meanwhile the extension host was logging canEnterAuto=true for the very same window.

The terminal CLI showed Auto normally at the same time, which made it look like the feature had been removed from the extension.

Environment

| | |
|---|---|
| Extension | anthropic.claude-code 2.1.270 (bundled CLI 2.1.270) |
| CLI (terminal) | 2.1.272 |
| OS | macOS 26.6.2 (25G83), arm64 |
| Model | claude-opus-5[1m] |

Symptoms

• Picker (both Shift+Tab cycling and the dropdown) listed only Manual, Edit automatically, Plan.
• The chat frame still rendered the orange Auto border, i.e. the webview's mode styling was out of sync with its own mode signal.
• Auto had been working in the same session earlier the same day — the session transcript records permissionMode: auto.
• No settings layer disabled it: no disableAutoMode in user settings, local settings, remote settings ({}), project settings, and no managed settings on the machine.

The contradiction

Every verifyAutoModeGateAccess line in the extension log — across every window, including during the failure — said Auto was fine:

[auto-mode] verifyAutoModeGateAccess: enabledState=enabled disabledBySettings=false
  model=claude-opus-5[1m] modelSupported=true disableFastModeBreakerFires=false
  carouselAvailable=true canEnterAuto=true

Extension host said yes; webview hid it anyway. Nothing reconciled the two.

Extension globalState also had the gate enabled:

experimentGates.tengu_auto_mode_state = "enabled"

Suspected cause

In webview/index.js, the webview does not consume the host's canEnterAuto. It re-derives availability from a model list it receives over the channel:

currentModelInfo = () => {
  let $ = IH(connection.value?.claudeConfig.value),   // [...models, ...unavailable_models]
      J = modelSelection.value || "default",
      Z = J.replace(/\[1m\]$/i, "");
  return $.find(Y => Y.value === J)
      ?? $.find(Y => Y.value === Z)
      ?? $.find(Y => Y.resolvedModel === J || Y.resolvedModel === Z);
}

currentModelSupportsAutoMode = () => {
  let $ = currentModelInfo.value;
  if (!$) return;                          // undefined when the lookup misses
  return $.supportsAutoMode ?? false;
}

autoModeAvailability = () => {
  let $ = config.value, J = currentModelSupportsAutoMode.value;
  if (!$ || J === undefined) return "unknown";   // ← the branch taken
  ...
}

and the picker:

if (availability === "available" || (availability === "unknown" && permissionMode === "auto"))
    n.push("auto");

So when the model list hasn't arrived (or the selection resolves to nothing), availability degrades to "unknown", and in that state Auto is hidden from exactly the users who are not already in Auto. The session's mode was default at the time, so the option disappeared.

Three issues compound here:

1. The authoritative verdict is ignored. The host already computed and logged canEnterAuto; the webview recomputes it from data that may not have arrived.
2. It fails silently. A missed lookup raises nothing — the option just vanishes, which reads to the user as "the feature was removed".
3. "unknown" is handled asymmetrically. Uncertainty hides Auto from the people who need to turn it on, while keeping it for those already inside it.

Workaround

Re-select the model with /model in the panel. Auto reappears immediately.

This works because set_model sends the full model object over the channel with the flag already set, so no lookup is needed:

{"type":"set_model","model":{"value":"opus[1m]","resolvedModel":"claude-opus-5[1m]",
 "displayName":"Opus (1M context)","supportsEffort":true,
 "supportsAdaptiveThinking":true,"supportsFastMode":true,"supportsAutoMode":true}}

Right after that, the log shows sessions spawning with permission mode: auto again.

A window reload was not required — no VS Code restart occurred between the failure and the fix.

Reproduction

Not deterministically reproduced. Observed on a resumed panel session. The timeline from one window's log:

• failure state present before 13:37
• three set_model events at 13:37:33–13:37:37
• Spawning Claude ... permission mode: auto at 13:40:14

Suggested fix

Have the webview trust the host's canEnterAuto (or at least fall back to it) instead of re-deriving availability from a model list that may be absent — and surface a diagnostic rather than silently removing the mode when resolution fails.

Relevant log path for anyone hitting this:

cd ~/Library/Application\ Support/Code/logs
grep -h 'verifyAutoModeGateAccess' "$(ls -t 2026*/window*/exthost/Anthropic.claude-code/*.log | head -1)"