Auto-mode classifier brownout: multi-hour intermittent failures on claude-opus-4-8[1m], sub-threshold on status page, no client-side retry

Summary

In auto mode, state-changing tool calls (Bash, and Write to permission-sensitive paths) are pre-approved by a two-stage safety classifier served on claude-opus-4-8[1m]. On 2026-07-04, that classifier path failed intermittently for ~3.5 hours and then recurred in bursts for ~8 more hours. When it fails, the harness fails safe and refuses the tool call outright — there is no client-side retry/backoff on the classifier call, and no fallback to interactive approval.

The main model and all read-only in-project tools worked continuously the entire time, so this was isolated to the classifier serving path — not the account, machine, or network.

All figures below are aggregate counts extracted from a session transcript and independently re-verified. No command contents, prompts, or project details are included.

Environment

| | |
|---|---|
| Claude Code | 2.1.199 (desktop app) |
| OS | macOS (Darwin 25.5.0) |
| Classifier model | claude-opus-4-8[1m] |
| Permission mode | auto (classifier-gated approval) |
| Scope | single project, single machine, single session |
| Session window | 2026-07-04 06:14:28 → 17:57:53 UTC |

Symptom / exact error strings

Two distinct signatures:

(1) Stage-1 unavailable — most common (63 of 69 unique failures):

claude-opus-4-8[1m] is temporarily unavailable, so auto mode cannot determine
the safety of Bash right now. Wait briefly and then try this action again...

(also observed as "the safety of Write" for a permission-sensitive path)

(2) Stage-2 error — less common (6 of 69), explicitly self-described as transient:

Permission for this action was denied by the Claude Code auto mode classifier.
Reason: Stage 2 classifier error - blocking based on stage 1 assessment
(usually transient — retrying often succeeds).

Signature 2 usually succeeded on one immediate retry; signature 1 generally did not.

Verified metrics

• 69 unique classifier failures: 63 stage-1-unavailable + 6 stage-2-error.
• Tool split: 64 Bash, 5 Write.
• 64 of 186 Bash tool calls failed classification ≈ 34% over the session.
• 18 identical commands both failed and later succeeded (flapping) — see below.
• First failure 06:54:22 (healthy for the first ~40 min); last failure 17:57:53.

Timeline (UTC, failures bucketed by 30 min)

06:30  #########            (9)   ← first failure 06:54:22
07:00  ##############################  (30)  ← dense window peak
07:30  ######               (6)
08:00  ##########           (10)
09:00  ################     (16)  ← burst starting ~09:24
17:30  #########            (9)   ← tail; last failure 17:57:53

Between the buckets shown, long stretches (e.g. 08:26–09:24, and most of ~09:30–17:30) were healthy. This was not a clean outage — it flapped.

Flapping characteristics (key diagnostic)

• Successes and failures interleaved within the same minute.
• No correlation with command content: 18 byte-for-byte identical commands failed and then succeeded seconds-to-minutes apart, with no change on the client side.
• This rules out prompt/content-based classifier denial and points squarely at serving-side availability of the claude-opus-4-8[1m] endpoint.

Gating matrix observed

| Call type | Gated by classifier? | Behavior during brownout |
|---|---|---|
| Bash state-changing (commit/push, PR create, package install, file removal) | Yes | Refused |
| Bash read-only inside project dir (listing, diff/status, in-file reads) | No | Worked 100% |
| Bash read-only outside project dir | Yes | Refused |
| Write to a permission-sensitive path (.claude/settings.json) | Yes | Refused — 5 consecutive failures 17:49–17:50 |
| Write/Edit to ordinary project files | No | Worked |

Catch-22: the documented workaround for a classifier outage is a permissions.allow allowlist in .claude/settings.json — but writing that file is itself classifier-gated, so it is also blocked during the outage. Landing it took 5 attempts across ~15 min.

Public status correlation

• status.claude.com: all components operational for the entire window; zero open incidents; page last updated 06:08 UTC (before the first failure).
• Incident history: "Elevated errors across many models" (impact: minor) ran 2026-07-03 23:42 → 2026-07-04 00:20 UTC — i.e. ~6.5h before the first failure here.
• Hypothesis: the daytime classifier brownout was a sub-threshold tail/recurrence of the same serving instability, localized to the claude-opus-4-8[1m] fast-serving deployment, that never re-tripped the public incident bar.

Ruled out

• Local machine / network — main-loop inference, GitHub API calls, a curl to the status page, and all in-project reads worked continuously.
• The commands themselves — identical commands succeeded on later retries (18 confirmed flaps).
• Content-based classifier denial — errors are "unavailable" / "stage-2 error", not policy denials; identical inputs both passed and failed.
• Concurrent-session rate limiting — failures continued when this was the only active session. (Account-level throttling of the classifier endpoint can't be fully excluded client-side, but the error text says "unavailable", not "rate-limited".)

Impact

• Auto-mode sessions cannot commit, push, open PRs, run installs, or write settings during the brownout. Work has to be staged with file tools and shipped in the healthy gaps.
• The error says "wait briefly and retry," but the condition lasted hours, and there is no client-side backoff/retry on the classifier call — each gated tool call fails immediately on the first classifier error.

Notable inconsistency in the client

The main-loop API client does retry transient failures with backoff (observed UI: Request failed · retrying (1/10) · 5s). The classifier call, in the same harness, does not — it fails the tool on the first error. Ask #3 below is essentially asking the classifier path to adopt the retry behavior the main loop already has.

Asks / questions

Server-side:

1. Server logs for the claude-opus-4-8[1m] classifier endpoint during 2026-07-04 06:54–09:25 UTC (and bursts through ~18:00 UTC): 5xx? overload / capacity shedding? Was this account-scoped or global?
2. Why did the "Claude Code" status component not reflect this? Is the auto-mode classifier dependency monitored at all?

Client behavior:

1. Should the harness retry/backoff the classifier call — especially the stage-2 error, which its own message calls transient — instead of failing the tool immediately? (The main loop already retries 10×; the classifier does not.)
2. Should classifier unavailability fall back to prompting the user for approval (as non-auto modes do) rather than refusing outright?

Reproduction / evidence

The two error signatures above are stable and greppable in a session transcript:

"temporarily unavailable ... cannot determine the safety of"   # stage-1
"Stage 2 classifier error"                                     # stage-2

Aggregate per-failure data (timestamp, signature, tool — no command contents) can be provided on request.