[BUG] Desktop 3P gateway: Auto mode not offered for Sonnet 5 (Opus 4.8 gets it), although the CLI reports supportsAutoMode: true and docs list Sonnet 5 as supported

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest neighbors: #51879, #53694, #44101, #60048, #55038 — see "Related issues" below)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Summary

Claude Desktop behind a 3P LLM gateway (inferenceProvider: "gateway", LiteLLM → Bedrock, /v1/models serving catalog ids): Auto mode (the classifier-based permission mode) is offered when claude-opus-4-8 is selected, but not when claude-sonnet-5 is selected.

Per the permission-modes docs, on Bedrock/Vertex/Foundry/gateway sessions Auto mode is supported by "only Claude Sonnet 5, Opus 4.7, and Opus 4.8" — so Sonnet 5 should offer it. The bundled CLI agrees: its per-model capability flag reports supportsAutoMode: true for claude-sonnet-5, in every provider constellation we tested. The greying/omission appears to happen in the Desktop UI layer, not in the worker.

Environment

• Claude Desktop (bundled CLI 2.1.209), macOS 15 (Darwin 25.5)
• 3P gateway: LiteLLM proxy in front of Amazon Bedrock; /v1/models returns catalog ids (claude-sonnet-5, claude-sonnet-4-6, claude-opus-4-8, claude-haiku-4-5)
• Managed config: {"inferenceProvider": "gateway", "inferenceCredentialKind": "helper-script", "autoModeEnabled": true, …} — Auto mode is org-enabled
• Worker spawn (from ps): --permission-mode auto present on sessions where Auto mode is active

Observed vs expected

| model selected in picker | Auto mode offered? | expected (docs + CLI flag) |
|---|---|---|
| claude-opus-4-8 | yes | yes |
| claude-sonnet-5 | no | yes |

Evidence that the worker is not the gate

1. list_models control request against the bundled CLI over the same gateway — both in the status-quo env (ANTHROPIC_BASE_URL + key) and in explicit gateway mode (CLAUDE_CODE_USE_GATEWAY=1) — returns the claude-sonnet-5 row with supportsAutoMode: true (same as Opus 4.8). Example row (gateway mode):

{"value":"claude-sonnet-5","resolvedModel":"claude-sonnet-5","displayName":"Sonnet","supportsEffort":true,"supportedEffortLevels":["low","medium","high","xhigh","max"],"supportsAdaptiveThinking":true,"supportsAutoMode":true}

1. The CLI's per-model gate (minified f3e in 2.1.209) only excludes legacy models (claude-3-*, Opus 4.0/4.1/4.5, Sonnet 4.0/4.5, Haiku 4.5) plus — on non-first-party providers — Opus 4.6, Sonnet 4.6 and Haiku. claude-sonnet-5 and claude-opus-4-8 both pass. Consistently, in the same install claude-sonnet-4-6 correctly loses the flag over the gateway while claude-sonnet-5 keeps it.

1. The CLI's auto-mode gate-denial reasons ("settings" | "circuit-breaker" | "provider" | "model") all evaluate to available for Sonnet 5 in this setup; org config has autoModeEnabled: true.

So the model rows delivered to the host say Sonnet 5 supports Auto mode, the docs say it's supported, but the Desktop UI doesn't offer it — pointing at a UI-side model-id allowlist/matching gate (same pattern as #55038, where a hardcoded model-id list fails to match provider-shaped ids).

Steps to reproduce

1. Claude Desktop with managed config inferenceProvider: "gateway" + autoModeEnabled: true, gateway exposing claude-sonnet-5 and claude-opus-4-8 via /v1/models.
2. Code tab, new session, select claude-opus-4-8 → open the permission selector → Auto mode is offered.
3. Switch to claude-sonnet-5 → Auto mode is absent/greyed.

Expected

Auto mode offered for claude-sonnet-5 per the documented 3P support matrix and the worker's own supportsAutoMode: true.

Related issues

• #51879 — Auto mode unavailable on Sonnet 4.6 while Opus works in the same install
• #53694 — Desktop silently rejects auto mode on Sonnet
• #44101 — Auto mode can't be enabled on Sonnet despite meeting all requirements
• #60048 — Auto mode not appearing for Sonnet in model selection
• #55038 — Auto mode gate uses a hardcoded model-id allowlist that misses provider-shaped ids (same failure pattern)
• #77247 — same environment; provider mis-resolution behind 3P gateways (different symptom, possibly shared plumbing)