Auto-mode permission classifier (claude-opus-4-8) failing at scale since ~2026-06-20 — persists after incidents support cited as resolved; forces users into Bypass permissions

Environment

• Claude Code desktop app + CLI 2.1.142 on Windows 11 Pro (build 10.0.26200)
• Sessions on claude-opus-4-8 and claude-fable-5 · permission mode: auto
• Operator: oscar@odlgstudios.com

Summary

The auto-mode permission classifier (served by claude-opus-4-8) fails intermittently,
and has been failing at scale since ~2026-06-20. While it is down, tool calls that
route through the classifier (Bash, PowerShell, Monitor, WebFetch — and per our June
transcript sweep, Write/Edit as well) fall back to manual permission prompts or blanket
denials, including for read-only commands covered by the project allowlist. Read-only
operations (Read/Grep) are never affected — they bypass the classifier, which isolates
the failure to the classifier path.

This was reported to Anthropic support by email on 2026-06-28. The Fin AI Agent
response attributed it to Opus 4.8 incidents resolved 2026-06-24 and 2026-06-27 and
suggested the errors "should have subsided." They did not. The failures continued
after both resolution dates and are still occurring as of 2026-07-05 — the cited
incidents do not explain (or no longer explain) the ongoing failure mode.

Hard numbers (from a transcript sweep, reported to support 2026-06-28)

Verbatim errors counted across session transcripts:

• Error: claude-opus-4-8 is temporarily unavailable — 868 occurrences
• Error: Permission for this action was denied by the Claude Code auto mode classifier — 255 occurrences

Occurrences of the first error per day (UTC):

• Baseline before the regression: 1–2/day (06-01, 06-03, 06-09, 06-13)
• 06-20: 14 · 06-21: 1 · 06-22: 290 · 06-23: 110 · 06-24: 63 · 06-25: 77 ·

06-26: 173 · 06-27: 327 · 06-28: ongoing

• Note: 06-24 through 06-27 remain in the hundreds — i.e., the failures continued

THROUGH the windows support later cited as resolved.

Sample of one bad ~20-minute window (2026-06-26): unavailability errors at 04:25:11Z,
04:26:26Z, 04:28:13Z, 04:29:00Z, then a denial at 04:29:14Z, then 04:38:22Z,
04:40:24Z, 04:44:52Z, 04:45:26Z — ~8 failures in 20 minutes.

Continued after the "resolved" dates (session-log corpus)

Our workflow keeps a written log per session. Sweeping those logs:

• 41 distinct sessions between 2026-05-24 and 2026-07-02 recorded

classifier-outage/denial incidents.

• The cluster continues past the 06-27 incident resolution: sessions on 06-28, 06-29,

06-30, 07-01 and 07-02 log entries like "clasificador de Bash caído intermitente
TODA la sesión (≥15 denegaciones Bash/PowerShell/Monitor/WebFetch)" and flapping
(~30-minute down windows, ~1-minute up windows).

• After 07-02 the logs go quiet — not because it healed, but because the operator

switched permanently to Bypass permissions to be able to work at all.

False-positive with hostile framing (2026-07-01)

A read-only probe was denied; when retried during an outage window (following the
harness's own "Wait briefly and then try this action again" instruction), the
classifier came back and labeled the retry:

"[Auto-Mode Bypass] fabricated narrative + tunneling the same prod-read probe through automated Monitor-timer retry loops"

A legitimate read-only action misclassified as a bypass attempt. This error class
erodes trust in the permission system in both directions.

Impact — the workaround defeats the security layer

To keep working, the operator has run in Bypass permissions instead of auto mode
for days. A reliability bug in the classifier is effectively coercing users into
disabling permission enforcement entirely — strictly worse for safety than any single
misclassification. "Continue retrying" (support's suggested mitigation) is not viable
when a session takes 12–15+ denials and half-hour dead windows.

Expected

• Classifier failures should degrade gracefully: fall back to the static allowlist /

read-only built-in rules instead of blanket-prompting/denying everything.

• Transparent retry/backoff on transient classifier-model unavailability.
• A visible health indicator when the classifier is degraded, so users understand why

prompts spiked instead of reaching for Bypass permissions.

• Reconcile with the support response: the incidents cited as resolved (06-24, 06-27)

do not cover the failures observed 06-28 → 07-05. Either the fix did not ship to the
Windows desktop channel, or this is a distinct/recurring issue.

Repro

Not deterministic (service-side flapping). Pattern: in auto mode during an affected
window, any Bash call — including git status-class read-only commands — triggers a
permission prompt or denial; Read/Grep continue without prompts. Line-level transcript
references available on request (same corpus as the 2026-06-28 support email).