[Bug] Anthropic API Error: Safety Classifier Unavailable - Auto Mode Blocked for Tool Execution

back to normal after deleting skipAutoPermissionPrompt: true from settings.json

I'm having this issue as well. Can't really use auto-mode at the moment because of this.

Got the same issue!

I have solution for this and trivial one.

remove allow command on user level and project level.
restart the claude.

basically just left it empty array
allow:[]

i am not lying, this works LOL.

Tried @zonblade 's fix. It _might_ be necessary, but it was not sufficient. I then changed "model": "claude-opus-4-6" to simply "opus". Again, potentially necessary, but ultimately not sufficient. Only upon removing "CLAUDE_CODE_ATTRIBUTION_HEADER": "0" from my user settings did auto-mode finally start to work without the classifier errors reported by @ahmad-asmar

Diagnostics
  ├ Currently running: native (2.1.133)
  ├ Commit: cba57ffec4f5
  ├ Platform: linux-x64
  ├ Path: /home/chb/.local/share/claude/versions/2.1.133
  ├ Config install method: native
  └ Search: OK (bundled)

  Updates
  ├ Auto-updates: enabled
  ├ Auto-update channel: latest
  ├ Stable version: 2.1.123
  └ Latest version: 2.1.133

  Version locks
  ├ 2.1.133: PID 1812926 (running)
  ├ 2.1.128: PID 249140 (running)
  └ 2.1.131: PID 400779 (running)

  Still having issues? Run /feedback to report details.

@socketbox OH! is this possibly had anything to do with how claude code auth themself? and classifier fail because it cannot auth itself when some "customization" applied 🤔🤔🤔

might be the case, and should be mentioned what to and what not but i could not figure out which other settings. dangg 😂

@zonblade solution worked for me, leave empty array on user settings
allow:[]

in my case, it seemed issue was partially related to "CLAUDE_CODE_SUBAGENT_MODEL": "opus" in my settings.json environment variables section
once I removed this, then seemed like classifier was working as expected _(I tried some combination of other suggestions as well, but nothing ultimately worked until I removed this setting)_

aside from this I also have explicitly mapped
"ANTHROPIC_MODEL": "opus",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-8",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-6",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-haiku-4-5"

finally, I am on anthropic Enterprise account in case that is relevant

does each update introduce different configuration? crazy lmao

Still reproducing on Claude Code 2.1.202 (Windows 11, claude.ai subscription auth, auto mode, session model claude-opus-4-8) — intermittent temporarily unavailable classifier failures on Bash/Agent/Write while main-loop chat streaming and read-only tools on the same model work flawlessly in the same session.

Two data points that narrow the cause, detailed in https://github.com/anthropics/claude-code/issues/63819#issuecomment-4910832559:

1. Failures are network-path-dependent: same machine and account failed all morning on my home network, worked flawlessly at the office, failed again immediately back home. Only the classifier side-query is affected — streaming is healthy on both networks.

1. My account's freshly-delivered tengu_auto_mode_config (GrowthBook cache refreshed minutes before posting, from the failing network) has no model field, so the classifier falls back to the session model per the fallthrough analysis in #60438 — even though the config's s1SuffixByModel only contains claude-sonnet-5 keys, suggesting Sonnet 5 is the intended classifier model. Pinning the classifier to its intended dedicated model server-side would likely make sessions on Opus immune to this failure mode.

Correction / update with debug-log evidence (--debug api) — supersedes my earlier "network-path-dependent" comment above, which was wrong.

I enabled api debug logging and captured the failing classifier call directly. The failure is HTTP 401 authentication_error ("Invalid authentication credentials") on the /v1/messages source=side_query call:

[Stall] classifier_request_finished ... stage=xml_s1 outcome=error durationMs=136 errorKind=Error:401
Auto mode classifier (XML) error: 401 {"type":"error","error":{"type":"authentication_error",
   "message":"Invalid authentication credentials"},"request_id":"req_011Ccop..."}
Auto mode classifier unavailable, denying with retry guidance (fail closed)

The crucial finding is the retry asymmetry. In the same session, at the same moment, the main loop receives the identical 401 on its source=sdk call:

[ERROR] API error (attempt 1/11): 401 {"type":"error","error":{"type":"authentication_error",
   "message":"Invalid authentication credentials"}, ...}

...but the main loop retries (up to 11 attempts), re-checks the token, and succeeds ("Stream started - received first chunk") — so chat appears seamless. The auto-mode classifier fails closed on the first error with no retry ("denying with retry guidance (fail closed)"), so every transient 401 becomes a blocked Bash/Write/Agent call.

This reframes the whole class of report:

• Not capacity / 529, not rate-limiting (429), not model unavailability. The user-facing string "<model> is temporarily unavailable, so auto mode cannot determine the safety of ..." is misleading — the underlying response is a 401 auth error.
• Not the network path. Reproduced on two different networks (home + cellular hotspot, different public IPs). Raw TCP+TLS to api.anthropic.com was healthy throughout (38–72 ms handshakes). The failures are instant app-layer 401s, not connection failures or timeouts.
• Not the classifier model choice. The client-side [API:auth] OAuth token check reports "complete" (valid) immediately before each server-side 401, so the token looks valid locally but is rejected server-side intermittently — consistent with a token-refresh race.

Environment: Claude Code 2.1.202 (desktop), Windows 11, claude.ai OAuth auth, session model claude-opus-4-8, auto mode. CLAUDE_CODE_CHILD_SESSION=1 (may be relevant if concurrent sessions/devices contend on OAuth token refresh).

Suggested fixes:

1. Give the auto-mode classifier the same 401 retry + token-refresh behavior the main loop already has, instead of failing closed on the first 401. This alone would eliminate the user-visible outage.
2. Fix the underlying intermittent 401 (token-refresh race — client-side token check passes while the server rejects).
3. Surface the real HTTP status in the error message rather than "temporarily unavailable," which sends everyone chasing capacity/network red herrings.