Auto mode: server-side safety classifier intermittently returns no verdict, blocking Bash and ScheduleWakeup entirely

Summary

In a Claude Code session running with Auto mode active, the Bash tool (and separately, the ScheduleWakeup tool) started failing with a server-side classifier error, for every call, including trivial ones like echo ok / pwd. The failure was total (100% of calls) for several minutes, then resolved on its own without any client-side action.

Observed error (verbatim, repeated on every call)

The server-side auto mode classifier gave no verdict (error), so auto mode cannot determine the safety of Bash. 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.

Same error text appeared for a ScheduleWakeup call during the same window (with "Bash" substituted for "ScheduleWakeup"), suggesting the outage was on the shared server-side classification service, not scoped to one tool.

Timeline

• Outage 1: several consecutive Bash calls (including a plain pwd) all returned the classifier error. Session paused and reported the issue to the user rather than retrying in a loop. On the user's next message, a retry succeeded immediately (pwd worked).
• Outage 2 (same session, later): a Bash call (grep/ssh one-liner) failed the same way, then ScheduleWakeup also failed the same way on the very next call. Session again stopped rather than hammering retries. On the user's next message, echo ok succeeded immediately.

In both cases nothing else about the environment or the command changed between the failing attempts and the successful retry — it self-resolved after some wall-clock time (not tied to a specific number of retries from this session, since the session deliberately stopped retrying and waited for the user's next turn instead).

Impact

• All Bash-based work (including SSH to remote hosts, git operations, running tests) is blocked for the duration of the outage, with no way to know in advance how long it will last.
• ScheduleWakeup being gated by the same classifier means a session can't even self-schedule a retry for later — it has to wait for the user to send another message, which defeats the "if it keeps failing, continue with other tasks and come back to it later" guidance when the thing you wanted to come back to is Bash/scheduling work.
• No visible way for the session (or the user) to check classifier health independently of just retrying a real tool call.

Suggested improvements (not required, just ideas)

• Expose a lightweight, low-cost way to probe classifier health without spending a "real" retry attempt against the growing-delay budget.
• Exempt ScheduleWakeup from the same classifier gate as Bash (or give it its own, since it's inherently a "come back later" mechanism and is most useful during an outage of some other capability).
• Surface an ETA or a "retry-after" hint in the error text if the backend has one, instead of an open-ended "may get a verdict later."

Environment

• Claude Code desktop app, Auto mode active, claude-opus-5-5 / claude-sonnet-5 (model was switched mid-session by the user; both were affected).
• Working in a git worktree of a private repo (unrelated to the failure — plain pwd/echo with no repo interaction also failed).