[Bug] Auto mode non-functional - insufficient error details for diagnosis
Status Fixed / completed
Reported on v2.1.217
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 4 comments · opened Jul 22, 2026 · closed Jul 27, 2026
Bug Description
Auto mode is completely broken and claude is not helping me root cause it
Environment Info
- Platform: darwin
- Terminal: iTerm.app
- Version: 2.1.217
- Feedback ID: 5bf76f8c-8fe4-4aaa-8a3d-afef65536d98
Errors
[]
4 Comments
Additional diagnostic detail from working through this with Claude Code itself.
Symptom: Auto mode's safety classifier fails on every Bash/Edit call with:
Read-only tools (Read, Grep, etc.) are unaffected — only actions that go through the auto-mode permission classifier fail.
Scope: 100% reproducible, across every terminal tab/session on this machine, for hours. Coworkers on the same models are unaffected, so this isn't a general Anthropic outage.
Ruled out during investigation:
claude-opus-4-8[1m],claude-sonnet-5, andclaude-haiku-4-5. Not model-specific.claudeharness integration is toggledoff;~/.claude/settings.jsonhas noANTHROPIC_BASE_URL/apiKeyHelper/model-remap overrides, and process env has no proxy vars. Ruled out.autoUpdateswasfalsein~/.claude.json, butclaude updateconfirms the client is current (2.1.217, latest). Not a version mismatch.settings.jsonconfig — checked all scopes (global, project, local, managed); nothing unusual in permissions, hooks, or env.Working workaround: switching out of auto mode (e.g.
acceptEdits/ default ask mode via/permissions) avoids the classifier entirely and works normally — so the account's normal chat/completions path is healthy. Only the auto-mode classifier call is failing, consistently, for this one account.This points at something account-specific on the backend (routing/entitlement/rate-limit tied to the auto-mode classifier service) rather than anything in local config — happy to provide more diagnostic info if useful.
Update: confirmed this is a known, recurring issue — not specific to my machine/account. Found a dozen+ similar reports while digging around, e.g. #49535, #63873, #38618, #74949 (open), and #38537/#68437/#69726 (closed, some with useful root-cause detail — #38537 traces the classifier inheriting the
[1m]context-window suffix into its own model selection, and #68437 confirms it can self-resolve with zero config changes, pointing to a service-side classifier availability problem rather than client config).Workaround that unblocked me, without disabling permission checks entirely:
Switch
defaultModefrom"auto"to"default"in~/.claude/settings.json:If you already have a reasonably complete
permissions.allowlist (e.g.Bash(git *),Bash(gh *),Bash(pnpm *),Edit(*),Write(*),Read(*), etc.), this preserves the "no prompts for trusted commands" experience — allow-list matches bypass both the classifier and the ask-prompt entirely. Only truly novel actions (outside the allowlist) fall back to asking directly, instead of routing through the broken classifier. No custom PreToolUse hook needed if your allowlist already covers your common commands.This isn't a fix for the underlying classifier bug — just a way to keep working while it's down. Flipping
defaultModeback to"auto"once the service-side issue clears should restore normal auto-mode behavior.<img width="985" height="661" alt="Image" src="https://github.com/user-attachments/assets/1dbc2c55-acaa-4bf2-8f70-5168e2885538" />
fixed by doing this
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.