Auto mode: server-side safety classifier repeatedly returns no verdict, blocking all write/exec tool calls (Edit, Bash, PowerShell)

Environment

• Claude Code desktop app, Code tab
• OS: Windows 11 Home Single Language 10.0.26200
• Model: Sonnet 5 (claude-sonnet-5)
• Permission mode: Auto mode
• Working in a local git repository (not a remote/cloud session)

Description

While working in an existing session, every write- or execute-capable tool call (Edit, Bash,
PowerShell) began failing with the same error, regardless of what the call actually did. This
persisted across multiple separate calls within a turn, across multiple turns, and even after the
user explicitly asked me to "try again" in a fresh message. Read-only tools (Read, Grep,
Glob) continued to work normally throughout — only tools that pass through the auto-mode safety
classifier were affected.

Error text (verbatim)

Per-call error:

The server-side auto mode classifier gave no verdict (error), so auto mode cannot determine the safety of Edit. This is a transient failure of the check, not a judgment about the action: a later response may get a verdict. You may try the action again once, as-is. Repeated attempts are slowed by a growing delay, and after 10 responses in a row without a verdict the turn stops. 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.

After 10 consecutive failures in one turn, the turn was terminated with:

Auto mode is unavailable: the server returned no safety verdict for 10 responses in a row, so Edit was not run and this turn has ended. Wait for the user's next message before doing anything further.

Steps to reproduce

Not reliably reproducible on demand — appears to be a transient server-side outage of the
classifier service. In this session it was triggered by ordinary, low-risk actions:

1. Edit on a local Markdown file to insert a documentation banner.
2. Bash/PowerShell running read-adjacent commands such as git diff --stat and ls.

Both kept failing with the same "no verdict" error across roughly a dozen attempts spread over
several user turns (one turn hit the 10-failure cutoff and ended automatically; a follow-up
attempt in the next turn also failed before recovering on a later retry after the user
re-engaged).

Expected behavior

The classifier either returns a verdict promptly, or the client falls back gracefully (e.g.
degrade to asking the user for manual approval) instead of leaving write/exec tools completely
unusable for an extended stretch with no path to recovery except waiting an indeterminate amount
of time.

Actual behavior

• All write/exec tool calls failed identically for an extended period (multiple minutes, spanning

several separate user turns).

• No indication of expected wait time or retry interval was given beyond "a growing delay."
• One turn was force-ended by the harness after 10 consecutive failures, requiring the user to

send a new message to resume.

• No way to bypass or manually approve the action despite it being clearly benign (editing a local

doc file, running git diff, checking gh auth status).

Impact

Blocked all file edits and shell commands for the affected stretch of the session; only read-only
exploration (Read/Grep/Glob) remained usable. Work had to be deferred and re-attempted across
multiple user turns before eventually recovering on its own.

Workaround used

None available — waited for user re-engagement and retried periodically; eventually resolved on
its own (exact recovery time not captured).