Auto mode hard-blocks Bash/Write/Edit when safety-classifier model (claude-opus-4-8[1m]) is unavailable — flapping outage, no fallback or retry

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 17, 2026

Summary

In auto permission mode, ALL mutating tool calls (Bash, Write, Edit) are hard-blocked whenever the safety-classifier model is unavailable, with no fallback, retry, or queue. Over a ~2-day window the classifier model (claude-opus-4-8[1m]) flapped repeatedly, blocking work in unpredictable bursts of seconds-to-tens-of-minutes.

Environment

  • Claude Code desktop-app harness (Agent SDK), Windows 11 Pro 10.0.26200
  • Session model: claude-fable-5 (also reproduced while session model was Opus)
  • Permission mode: auto
  • Dates observed: 2026-07-16 and 2026-07-17 (US Central)

Verbatim error

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. If it keeps failing, continue with other tasks that don't require this action and come back to it later. Note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.

(same text with "Write" / "Edit" substituted for those tools)

Observed characteristics

  1. Flapping, not a single outage: identical calls alternate pass/fail within minutes. Example sequence observed: gh pr merge one-liner PASSES, then a 35-line heredoc FAILS twice, then a commit PASSES ~2 min later. Down-windows ranged from <1 min to ~15 min, recurring across two days.
  2. The classifier is pinned to claude-opus-4-8[1m] regardless of session model — switching the session to another model does not route around the unavailable classifier.
  3. dangerouslyDisableSandbox: true does not bypass the block (classifier runs pre-sandbox).
  4. Read-only tools (Read/Grep/Glob, read-only MCP) keep working, as the message states.
  5. Anecdotally, longer payloads seemed to fail more often than one-liners during degraded windows, though a tiny printf write also failed once — so it looks like time-based capacity flapping, possibly load/size-weighted.
  6. Background Bash tasks already running are unaffected; only NEW tool calls are gated.

Impact

Multi-hour engineering sessions degrade into retry loops: an agent mid-lane (commit/push/PR sequences) is repeatedly interrupted, must chunk file writes into tiny heredoc appends to slip through up-windows, and cannot arm background watchers. There is no programmatic signal for "classifier healthy again" — the only strategy is blind retry.

Suggestions

  • Fallback classifier model (e.g., current-generation small model) when the primary is unavailable, or a locally cached allowlist for commands the same session already approved verbatim.
  • Exponential-backoff auto-retry inside the harness instead of surfacing a hard error per call.
  • A health signal (or queueing) so agents/users know when to resume rather than probing.
  • Consider not re-classifying byte-identical commands that passed moments earlier in the same session.

Repro

No deterministic repro (server-side availability); the pattern above reproduced dozens of times across two sessions on 2026-07-16/17.

View original on GitHub ↗