[BUG] Auto mode blocked by persistent "safety classifier temporarily unavailable" outage — Edit/Write/Bash all fail
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
In an active Claude Code session with auto mode enabled, every call to Edit, Write, and Bash has been
failing for ~30+ minutes with this error:
claude-opus-4-6[1m] is temporarily unavailable, so auto mode cannot determine
the safety of Edit 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.
The same error triggers for Bash and Write. Read-only tools (Read, Grep, Glob, WebFetch) continue to work
normally.
Impact
The assistant cannot make any file changes or run any shell commands. This means real work (editing a CSS
file, creating new components, running a dev server, gh issue create, etc.) is fully blocked even though the
user has explicitly authorized the work via approved plans + auto mode.
What Should Happen?
When the auto-mode safety classifier is unavailable, Claude Code should not hard-fail every write/exec tool
call. Any one of these would be an acceptable degradation:
- Graceful fallback to confirm-per-action. Treat classifier-unavailable as equivalent to "needs user
confirmation" — surface a single approval prompt per tool call and let the user override, instead of
blocking the tool entirely. This matches how the app already handles tools that aren't pre-approved.
- Clear status + ETA surfacing. If the classifier is down, show a session-level banner with a status
indicator and an approximate ETA (e.g. "Classifier degraded — retrying in 2m"), so users can decide whether
to wait, switch mode, or abort. Right now the only signal is a per-call error that looks transient but
persists for 30+ minutes.
- Automatic drop from auto mode to default. If the classifier fails more than N times in a row within a
short window, automatically exit auto mode back to the default permission mode and notify the user in the
UI, so work resumes under standard per-action confirmations without a full restart.
Additionally, the error message itself should be accurate — it currently references claude-opus-4-6[1m] as
the unavailable model even when the user has explicitly selected Opus 4.7. That string should reflect the
actual classifier model, or be generalized (e.g. "safety classifier temporarily unavailable") to avoid
implying the user-selected model is the problem.
Today, the classifier outage functionally bricks the session: no edits, no shell, no Agent delegation
(sub-agents hit the same block). Read-only tools continue to work, which confirms the rest of the pipeline
is healthy — only the safety-review path is blocked.
Error Messages/Logs
Error: claude-opus-4-6[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.
Steps to Reproduce
These steps describe the exact session state that triggered it and the diagnostic signals the
Anthropic team can match against their logs.
- Launch Claude Code against any local Next.js repo (not required, but mirrors what I was doing — any
codebase works).
- Enable auto mode (/auto or via CLI flag). Confirm the "Auto mode active" system-reminder appears.
- Confirm model is Opus 4.7 via /model — the session header shows "Opus 4.7 (1M context)".
- Ask the assistant to make a substantive change (in my case: extending app/globals.css with ~60 lines of
new CSS variables and utility classes). Approve the plan if in plan mode so auto-mode execution begins.
- The assistant invokes the Edit tool with a normal, non-destructive diff.
- Instead of the edit applying, the tool returns this exact error text (captured verbatim from the
session):
claude-opus-4-6[1m] is temporarily unavailable, so auto mode cannot determine
the safety of Edit 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.
- Retry the same Edit 5–10 times over 10+ minutes — same error every time.
- Try the same change via a general-purpose sub-agent (Agent tool). Sub-agent fails with the same
underlying classifier block and returns: "The safety classifier was unavailable when reviewing this
sub-agent's work".
- Try Bash (e.g. gh auth status) — same error with "safety of Bash" in the text.
- Try Write on a brand-new file — same error.
- Try Read / Grep / Glob / WebFetch — all succeed normally, confirming only the safety-review path is
degraded, not the overall session.
Diagnostic signals to match in logs:
- Affected tools: Edit, Write, Bash, Agent (sub-agent dispatch)
- Unaffected tools: Read, Grep, Glob, WebFetch, Skill, TaskCreate/Update, ScheduleWakeup
- Error string references model id claude-opus-4-6[1m] as the classifier, even though the user-selected
model is claude-opus-4-7
- Session persisted through multiple /model toggles and multiple scheduled ScheduleWakeup retries — none
resolved it.
Minimum repro attempt (if classifier is currently healthy, this will just work):
mkdir -p /tmp/claude-classifier-repro && cd /tmp/claude-classifier-repro
echo ":root { --x: red; }" > test.css
Then ask Claude Code in auto mode: "edit test.css to change --x to blue". Expected when healthy: edit
applies. Observed during outage: the classifier-unavailable error above.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.112 (Claude Code)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗