[BUG] Auto-mode permission classifier ignores CLAUDE_CODE_AUTO_MODE_MODEL and always uses the session model

Status Open
Reported on v2.1.245
Maintainer reply None cached
Activity 1 comment · opened Oct 10, 2026

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_MODEL set correctly in the env block of ~/.claude/settings.json
  • the ANTHROPIC_DEFAULT_SONNET_MODEL alias (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_MODEL is 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.
  • Agent tool 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)

  1. Honor CLAUDE_CODE_AUTO_MODE_MODEL when selecting the classifier model (preferred — decouples classifier compatibility from session model choice).
  2. On classifier failure, fall back to a manual permission prompt instead of hard-failing the tool call.
  3. 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_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗