[BUG] Auto-mode permission classifier ignores CLAUDE_CODE_AUTO_MODE_MODEL and always uses the session model
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?
Auto-mode permission classifier ignores CLAUDE_CODE_AUTO_MODE_MODEL and always uses the session model
Version: latest channel, VS Code extension — fill from claude --version
Platform: Windows 11, VS Code extension, Git Bash
Setup note: repro uses a third-party Anthropic-compatible endpoint (ANTHROPIC_BASE_URL → Fireworks) with aliases remapped via ANTHROPIC_DEFAULT_*_MODEL. The env-var-ignored bug should be provider-independent
What Should Happen?
Auto-mode should use the model selected by CLAUDE_CODE_AUTO_MODE_MODEL
Summary
CLAUDE_CODE_AUTO_MODE_MODEL is present in the CLI's env-var schema but is not honored. The auto-mode permission classifier always uses the session's chat model, regardless of:
CLAUDE_CODE_AUTO_MODE_MODELset correctly in theenvblock of~/.claude/settings.json- the
ANTHROPIC_DEFAULT_SONNET_MODELalias (the classifier's traditional default) CLAUDE_CODE_SUBAGENT_MODEL
Secondary: when the classifier's request to the model fails, the user-visible error is"<model> is temporarily unavailable, so auto mode cannot determine the safety of Bash right now. Wait a moment and then try this action again."
This reads as a transient outage and advises a retry that can never succeed, when it is actually a permanent model/request incompatibility.
Expected behaviour
CLAUDE_CODE_AUTO_MODE_MODELis honored for the classifier request (its presence in the env-var schema suggests it was meant to be).- Non-retryable classifier failures surface the real cause — or fall back to prompting the user in manual mode — instead of "temporarily unavailable … try again".
Notes:
- A full VS Code window reload (guaranteeing fresh
env) does not change the outcome. Agenttool launches are themselves classifier-gated and fail identically in this state, but tool calls inside running subagents are unaffected.
Suggested fixes (any one suffices for the first point)
- Honor
CLAUDE_CODE_AUTO_MODE_MODELwhen selecting the classifier model (preferred — decouples classifier compatibility from session model choice). - On classifier failure, fall back to a manual permission prompt instead of hard-failing the tool call.
- At minimum, surface the underlying error so users can self-diagnose instead of waiting out a non-existent outage.
Error Messages/Logs
Steps to Reproduce
Reproduction
CLAUDE_CODE_AUTO_MODE_MODEL set to a classifier-compatible model in settings.json → env (verified present after a full VS Code window reload). Toggle only the session model via /model and the alias mapping, then run any Bash command not covered by permissions.allow:
ek Flash (via sonnet) | DeepSeek Flash | ✅ works |
| 3 | GLM 5.3 (
| # | Session model (via alias) | ANTHROPIC_DEFAULT_SONNET_MODEL | Classifier result |
|---|---|---|---|
| 1 | GLM 5.3 (via sonnet) | GLM 5.3 | ❌ fails, error names session model |
| 2 | DeepSevia opus) | DeepSeek Flash | ❌ fails |
| 4 | DeepSeek Flash (via sonnet, after full window reload) | DeepSeek Flash | ✅ works |
Row 3 is the decisive case: the Sonnet alias points at a classifier-compatible model while the session model does not, and the classifier still fails — proving it binds to the session model, not the Sonnet alias and not the env var.
Claude Model
Other
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.245
Platform
Other
Operating System
Windows
Terminal/Shell
VS Code integrated terminal
Additional Information
_No response_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗