[Bug] Auto mode non-functional - insufficient error details for diagnosis

Status Fixed / completed
Reported on v2.1.217
Maintainer reply None cached
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

[]

View original on GitHub ↗

4 Comments

jam3gw · 2 months ago

Additional diagnostic detail from working through this with Claude Code itself.

Symptom: Auto mode's safety classifier fails on every Bash/Edit call with:

claude-<model> is temporarily unavailable, so auto mode cannot determine the safety of <Bash|Edit> right now.

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:

  • Model choice — identical failure on claude-opus-4-8[1m], claude-sonnet-5, and claude-haiku-4-5. Not model-specific.
  • Third-party provider routing (Fireworks FireConnect) — installed on this machine but its claude harness integration is toggled off; ~/.claude/settings.json has no ANTHROPIC_BASE_URL/apiKeyHelper/model-remap overrides, and process env has no proxy vars. Ruled out.
  • Stale CLI build — autoUpdates was false in ~/.claude.json, but claude update confirms the client is current (2.1.217, latest). Not a version mismatch.
  • Project/user settings.json config — 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.

jam3gw · 2 months ago

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 defaultMode from "auto" to "default" in ~/.claude/settings.json:

"permissions": {
  "allow": [ ... ],
  "defaultMode": "default"
}

If you already have a reasonably complete permissions.allow list (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 defaultMode back to "auto" once the service-side issue clears should restore normal auto-mode behavior.

jam3gw · 2 months ago

<img width="985" height="661" alt="Image" src="https://github.com/user-attachments/assets/1dbc2c55-acaa-4bf2-8f70-5168e2885538" />

fixed by doing this

github-actions[bot] · 23 days ago

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.