Auto mode classifier (claude-opus-4-8) repeatedly unavailable — blocks Bash/Write/Edit

Same issue here.

same issue with opus 4.8

Same failure on Claude Max (20x), and I've eliminated every client-side cause by test — including the [1m] fix from #38537. The real error is a 429 rate_limit_error, not a model outage.

Environment: Claude Max (20x) · macOS (Apple Silicon) · Claude Code v2.1.177 (also reproduced on 2.1.173) · started ~2026-06-12 21:00 UTC, persisted 12h+.

The actual error. The UI text ("<model> is temporarily unavailable") is misleading. claude --debug api shows the classifier side_query getting a 429 rate_limit_error, retried 5× then fail-closed:

[auto-mode] context comparison: classifierChars=46622 (sys=46049 tools=85 user=488)
classifier_request_started reqId=… tool=Bash model=claude-opus-4-8[1m] stage=xml_s1
[API REQUEST] /v1/messages source=side_query        (x5 retries over 12s)
classifier_request_finished outcome=error durationMs=12187 errorKind=Error:429
  {"type":"error","error":{"type":"rate_limit_error"},"request_id":"req_011CbzrAP8gRHnJYqT3M9Nuj"}
Auto mode classifier unavailable, denying with retry guidance (fail closed)

This is not the plan quota — session was ~2% / weekly 0% at the time.

Everything ruled out by test:

| Tested | Result |
|---|---|
| Plan quota | 0% weekly — not it |
| Model: opus-4-8[1m], non-1M opus-4-8, sonnet-4-6 | all 429 (so it's not just the [1m] passthrough from #38537 — non-1M fails too) |
| CC version 2.1.173 → 2.1.177 | all fail |
| skipAutoPermissionPrompt removed (per #38618) | no change |
| OAuth token (full logout/login) | no change |
| System clock / NTP | in sync |
| Concurrent sessions / background API consumers | none; killed all — still fails |
| Network family: forced IPv4 (networksetup -setv6off) | still fails |

Cross-machine smoking gun: the same Max account on a Hetzner server (different IP/region) runs the classifier fine (Allowed by auto mode classifier) at the same time the Mac consistently 429s. So it's account/region/edge-side, not the client, model, or my network.

The architectural issue (per @danmana, @DavidPluxia in #38537) stands: pinning the safety classifier to a single flagship model with no fallback turns any per-account/region rate-limit or capacity blip into a total auto-mode outage — and it fails closed silently (the /permissions "Recently denied" tab stays empty). "Fixed in v2.1.112" did not resolve it.

Asks:

1. Add a fallback classifier model (e.g. non-1M Sonnet) when the primary returns 429/5xx — a SPOF on one model is the root design flaw.
2. Surface the real underlying error (429 rate_limit vs overload) in the UI instead of a generic "temporarily unavailable."
3. Investigate why side_query/classifier requests get 429'd at ~0% plan usage for specific accounts/regions while normal generation on the same account/IP succeeds.

Happy to share the full --debug api log and request IDs.

Same issue here.

Same issue here.

Same issue here.

Same issues

same issue 2 days in a row

Come on guys! 20x plan which I can't use properly, even when the model is up

Same issue for days. ditto @mattnelsonuk

Check out https://github.com/anthropics/claude-code/issues/64585 for a potential fix. CLAUDE_CODE_ATTRIBUTION_HEADER=0 breaks auto mode.

Same. Very annoying. Happening all the time now.

Additional data point: failures are network-path-dependent on my setup, and my account's tengu_auto_mode_config is being delivered without a model field

Setup: Claude Code 2.1.202 (desktop entrypoint), Windows 11, claude.ai subscription auth, session model claude-opus-4-8, auto permission mode.

Symptoms (2026-07-07, US Central, continuing into 2026-07-08 UTC):

• Intermittent all day: claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now. Same for Agent and Write. Roughly half of classifier-gated calls failed during bad stretches.
• Main-loop Opus 4.8 chat streaming in the same session never hiccuped once, and read-only tools (Read/Grep/Glob) were unaffected. Only the classifier side-query fails.

Three observations that may help triage:

1. Network-path dependence, same machine + same account. Failures all morning on my home network; disappeared entirely while I was at the office; resumed immediately when I got back home. Whatever is failing is sensitive to the network path, but only for the classifier side-query — the streaming main loop is healthy on both networks.

1. Classifier follows the session model — mostly. With the session switched to claude-sonnet-5, the next 5 classifier-gated calls succeeded immediately, then a later call failed citing claude-sonnet-5 (so switching appears to reduce but not eliminate; small sample, not conclusive). With the session on claude-fable-5, the failure message cited claude-opus-4-8[1m] — a model not selected in the session, with the [1m] suffix (cf. #38537).

1. My account's delivered tengu_auto_mode_config has no model field. From cachedGrowthBookFeatures in ~/.claude.json, refreshed 2026-07-08T02:25Z (minutes before this comment, from the failing home network — so this is fresh server delivery, not a stale cache):

"tengu_auto_mode_config": {
  "enabled": "enabled",
  "twoStageClassifier": true,
  "sameTurnSiblingContext": true,
  "jsonlTranscript": true,
  "editRemovalVisibility": true,
  "editRemovalCap": 3000,
  "outcomeVisibility": true,
  "s1SuffixByModel": {
    "claude-sonnet-5": "...",
    "claude-sonnet-5[1m]": "..."
  }
}

This matches the fallthrough analysis by @aguynamedryan in #60438 (config without model → classifier falls back to the session model). Notably s1SuffixByModel only has keys for claude-sonnet-5 / claude-sonnet-5[1m], which suggests the classifier is intended to run on Sonnet 5 — but with model absent, my sessions run it on whatever the session model is (Opus 4.8 most of the day), which appears to be far less reliable on the classifier path.

CLAUDE_CODE_ATTRIBUTION_HEADER is unset (so not #64585). No proxy env vars set. Happy to provide debug logs / request IDs if useful.

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.

same issue with macOS

Confirming the 401 analysis above from a second, independent environment — and reporting how we resolved it on our side, with 10 days of quantified data and one new signal that supports the token-refresh-race hypothesis.

How we resolved it (same day)

A cold re-login of the brokering Desktop app (full logout → fresh /authorize), rotating the entire brokered token family — done at ~09:45 UTC, right after updating the Desktop bundle (CLI → 2.1.205). Measured since, under the same parallel load that used to trigger storms:

• [oauth] CLI requested token refresh after 401 in the Desktop logs: 0 lines (vs 92 earlier that same day, 1620/day at peak).
• 0 classifier refusals in any session transcript — counted from actual error records (not message text), with concurrent cowork sessions, subagent fan-out, and dozens of classifier-gated Bash/Agent calls, all approved.

In parallel, we added narrow deterministic permissions.allow rules for recurring safe commands. Those resolve before the classifier, so even a future 401 storm now has a much smaller blast radius (only protected-path writes, Agent spawns, and unlisted commands still hit the classifier).

Caveat: storms were episodic before (Jul 5–9 were quiet with no intervention), so a same-day zero is a strong signal, not proof — I'll re-run both counters after 7 days of normal parallel load and report back either way. A fresh token also only removes the trigger: the classifier's no-retry fail-closed design is what turns any transient 401 into an outage, so the suggested fixes below remain the real product fix.

Supporting data

Environment: Windows 11, Claude Code 2.1.197 → 2.1.202 during the affected window (Desktop app / cowork-managed CLI, %APPDATA%\Claude\claude-code\<version>\), claude.ai OAuth, heavy use of parallel sessions and subagents (CLAUDE_CODE_CHILD_SESSION=1 present).

Scale of user impact (from session transcripts, July 2–12):

• 456 "cannot determine the safety of X" refusal messages across 88 session files, continuously over 10 days and two client versions (so not a regression introduced by one release).
• Breakdown of the 370 refusals I could join to their originating tool call: Bash 151, PowerShell 91, Edit 92 + Write 29 (all on protected .claude/** paths, which route to the classifier even when allow rules match), Agent 44, plus scattered Read/Grep/WebFetch/MCP calls — i.e. when the classifier side-query 401s, any pending tool call is denied.

New signal — the Desktop app's own logs corroborate an auth-refresh storm, correlated with parallel load:

%APPDATA%\Claude\logs\main*.log contains the line [oauth] CLI requested token refresh after 401. Counting per day:

| Day | count |
|---|---|
| baseline (mid-June onward) | 1–3/day |
| Jul 3 | 1620 |
| Jul 4 | 572 |
| Jul 5–9 | ~0 |
| Jul 10 | 120 |
| Jul 11 | 346 |
| Jul 12 | 92 — a single burst 05:47–06:14 UTC; 0 since the ~09:45 UTC token rotation |

The storm days are exactly the days with (a) massive classifier refusals in transcripts and (b) heavy parallel subagent fan-out. Since the Desktop app brokers the OAuth token for all cowork sessions and their child sessions, this is consistent with the refresh-race hypothesis proposed above (one process refreshes → sibling sessions' access token is invalidated → cascade of 401s; the main loop retries and recovers, the classifier side-query fails closed on first error). It is not consistent with capacity issues (would not correlate with local parallelism) or network path (per the earlier comment's TCP/TLS evidence).

On the misleading message: strings in the bundled CLI binary show the classifier denial path is explicitly fail-closed ("Auto mode classifier unavailable, denying with retry guidance (fail closed)") while the user-facing message reports the model as "temporarily unavailable" without the HTTP status the client received. The official error docs also currently classify this message as a transient overload — which sends affected users chasing capacity/network red herrings instead of auth.

Suggested fixes (echoing the thread, plus two)

1. Give the classifier side-query the same 401 retry + token-refresh behavior the main loop already has (this alone removes the user-visible outage).
2. Fix the underlying refresh race for Desktop-brokered tokens under concurrent sessions/child sessions.
3. Surface the real HTTP status in the error message instead of "temporarily unavailable".
4. Log these denials under /permissions → "Recently denied" (currently they leave no in-product trace, which makes diagnosis needlessly hard).

Workarounds that held up for us, for anyone affected

(a) the remedy that actually worked: cold re-login of the Desktop app (logout → login) to rotate the brokered token; (b) narrow deterministic permissions.allow rules for your recurring safe commands — they resolve before the classifier and are immune to the 401 (note: broad rules are dropped on entering auto mode, and Rule(prefix:*) takes the prefix literally — write narrow Tool(cmd *) rules); (c) during a storm, switch the session out of auto mode (mode selector) so denials become approvable prompts; (d) reduce parallel fan-out on storm days.