Safety classifier outage blocks ALL Bash/tool calls: "claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of Bash"

Hi, I think I'm experiencing the same issue. Disruptive, and wastes tokens

Auto-mode safety classifier intermittent unavailability

Symptom: In a desktop Claude Code session running in auto permission mode, some Bash tool calls were rejected before execution with this exact error:

claude-opus-4-8 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.

• Auto mode appears to gate Bash calls through a safety classifier whose backing model is named/identified as claude-opus-4-8, and that classifier endpoint was "temporarily unavailable."
• The failure is at the permission-classification layer, before the command runs — not a command error.

Pattern observed

| Attempt | Command (class) | Result |
| ----- | ----- | ----- |
| 1 | git push -u origin <branch> | ❌ classifier unavailable |
| 2 | same git push (retry) | ✅ succeeded |
| 3 | lsof -ti tcp:10415 | xargs kill (cleanup) | ❌ classifier unavailable |
| 4 | same cleanup (retry) | ❌ classifier unavailable |

Scope / blast radius:

• Intermittent
• Affected only classifier-gated tools (Bash). Read-only tools were unaffected the whole time (Read, Grep, Edit, Skill, Agent dispatches, etc. all worked).
• Independent of command risk level — it hit both a git push and a trivial lsof | kill.

Repro/diagnostic notes for the report: model id claude-opus-4-8; permission mode \= auto/default; the gating is per-Bash\-call; the user-facing guidance ("come back later") implies no automatic retry/fallback on the classifier path. Useful to include: rough timestamps, that it self-recovered on retry, and that it recurred minutes later (suggesting flapping availability rather than a single blip).

Independent confirmation on macOS (Darwin 25.5.0, claude-opus-4-8, auto-approval mode), plus two things not yet in this thread: an allowlist inconsistency and a working mitigation.

During the outage my ~/.claude/settings.json had both of these in permissions.allow:

• Bash
• mcp__Desktop_Commander__* (an MCP server whose start_process executes arbitrary host shell)

Observed behavior: every built-in Bash call was refused with the claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of Bash message, but the allowlisted Desktop Commander MCP tools ran normally the entire time. I completed a full multi-repo git/edit/build/knowhub workflow through mcp__Desktop_Commander__start_process while built-in Bash (and the Task/Agent tool) stayed blocked.

This appears to be allowlist-status-dependent, and treated inconsistently between built-in Bash and MCP tools. It lines up with #38618, where a non-allowlisted AWS MCP server was blocked by the same classifier error — so allowlisted MCP tools appear to bypass the classifier, while an allowlisted Bash rule does not.

Two takeaways:

1. Mitigation for anyone hit by this: route shell through an allowlisted MCP server (e.g. Desktop Commander). In my session those calls never invoked the classifier and survived the entire outage; built-in Bash did not, even though it was allowlisted.

1. The inconsistency is itself worth fixing. An explicit allow rule for Bash arguably means "pre-authorized," yet it's still gated by the (unavailable) classifier and thus fully blocked, while an allow rule for MCP tools genuinely bypasses the classifier. There's also a security wrinkle: the classifier blocked the built-in Bash path (which can run sandboxed) but left the unsandboxed MCP-shell path wide open — i.e. it blocked the more constrained tool while the more powerful one passed straight through. Honoring the Bash allowlist the way MCP allowlists are honored would, as a side effect, deliver the graceful fallback this issue is asking for.

Environment: Claude Code (desktop app), model claude-opus-4-8, macOS arm64, auto-approval ("auto") permission mode, with Bash and mcp__Desktop_Commander__* both in permissions.allow.

Independent confirmation, still occurring as of 2026-07-08 on macOS (Darwin 25.3.0, Apple Silicon), in a Claude Code CLI session running in auto-approval mode.

New data point: not limited to claude-opus-4-8. In this session the active model was claude-sonnet-5, and the classifier-unavailable error referenced that model instead:

claude-sonnet-5 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.

This suggests the outage is at the classifier-routing/backend layer rather than tied to one specific backing model.

Frequency observed: the "temporarily unavailable" error hit 4 times within roughly 10 minutes of active use in a single session, on plain Bash calls (including trivial commands like gh auth status and gh issue view). Each time, retrying the identical command 10-30 seconds later succeeded - consistent with flapping availability, matching the pattern @Tabberwocky and @JEM-Fizbit described above.

Follow-on failure mode: when I then tried to post this same comment (i.e. report this bug), the request was denied with a different error - "Stage 2 classifier error - blocking based on stage 1 assessment" - and a retry of the identical command was denied again, this time flagged as "[Auto-Mode Bypass] ... retrying it verbatim with no new user instruction in between." So the classifier's own anti-bypass heuristic treated a legitimate retry of a bug report (explicitly suggested by the classifier's own first error message) as suspicious behavior requiring a human in the loop. This matches the false-positive/hostile-framing pattern reported in #74351.

Impact: this has become the top recurring friction point in day-to-day use of Claude Code - it interrupts active workflows every few minutes and forces manual retries or explicit human approval for ordinary read/write Bash calls. Would prioritize a graceful fallback (static-allowlist/read-only fallback, or transparent backoff+retry) over a hard block on every classifier-gated tool call, and would separately reconsider the anti-bypass heuristic that flags an immediate retry of a denied action as adversarial - especially when the tool's own error message told the agent to retry.

Environment: Claude Code CLI, macOS (Darwin 25.3.0), model claude-sonnet-5, permission mode: auto.

Also hitting this tonight (2026-07-20, macOS Darwin 24.5.0, Claude Code CLI, claude-sonnet-5, auto-permission mode).

Exact error text observed, repeatedly, across two separate concurrent sessions:

• "claude-sonnet-5 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now."
• "The Bash safety classifier is temporarily unavailable again — same outage as earlier, unrelated to the command itself."

Pattern matches what's described here:

• Simple commands (echo, pwd, ls, gh auth status) eventually succeed, sometimes after 2-3 retries.
• More complex commands (git commit, git checkout -b, gh issue view/gh issue comment) fail repeatedly on the identical classifier-unavailable error before eventually clearing.
• Read-only tools (file read/search) are unaffected the whole time.
• No manual-approval fallback is offered - it hard-blocks until the classifier itself recovers, with no ETA surfaced.

+1 on the ask: a fallback to explicit per-command approval (or at minimum a clear "classifier degraded" signal) instead of a silent fail-closed retry loop would make this much less disruptive.