Claude Code auto mode: Bash, MCP and Agent calls fail with `The server-side auto mode classifier gave no verdict (error)`, and the turn stops after 10 in a row

Context

Source(s): https://github.com/anthropics/claude-code/issues/97854 Status: reported working by source, not reproduced by us (workaround only; root fix not confirmed).

Problem

With auto mode on, every Bash call fails with the error above, even pwd or echo ok. The same error names other tools in place of Bash: ScheduleWakeup, Agent (including subagent launches), WebSearch and MCP tools such as mcp__<server>__<tool>. Reading files and searching code keep working. A commenter found that the count of 10 is shared across tool types, so a multi-step task can stop in the middle; in their case an edited file stayed unstaged because the git add was the call that hit the limit, and the stop message did not say so. Another commenter said each failed attempt still uses a turn.

Error (redacted / normalized)

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.

Auto mode is unavailable — the server returned no safety verdict for the last 10 responses, so Claude stopped. Send a message to try again, or switch out of auto mode.

Applies when

Claude Code desktop app, CLI 2.1.283 and the VS Code extension, on macOS, Linux, Windows and WSL2; models claude-opus-5-5, claude-sonnet-5 and Sonnet 5.5; reported 2026-09-28 to 2026-10-01; later comments (to 2026-10-18) add workarounds and tools, not new reports. A commenter on a third-party model endpoint saw a version that never cleared within a session.

Confirm it is this problem

1. The failing tool call returns the text above, with the tool name in place of Bash → expect: an exact match up to the tool name.
2. Run a read-only step, for example ask Claude to read a file → expect: it works while Bash still fails.

Not this when / boundary

The message says the classifier blocked or refused the action; that is a verdict about the action, not this outage (our inference). API Error: Opus 5.5's safeguards flagged this message is a different error; a commenter saw it in the same time window, and the thread has no fix for it.

Root cause

The safety check that auto mode runs before each non-read-only tool call is answered by a server, and that server returned no verdict. The original poster saw it clear by itself after some time, and a commenter called it intermittent and server-side. The issue is still open and the thread has no statement from Anthropic about the cause (our inference).

Variables

<server> and <tool>: the MCP server and tool names in the error.

Fix

1. Wait a little and send another message in the same session → expect: the original poster said a retry on their next message worked at once, twice. A commenter said a new message also resets the count of 10, so you don't have to throw the session away.
2. If it keeps failing: switch the session out of auto mode to the default permission mode or Accept Edits, run a few tool calls there, then switch back to auto mode → expect: one commenter said leaving auto mode for the default mode fixed it at once; another switched to manual approval for about 5 calls, then back to auto, and it worked; a third does this with Accept Edits each time the error appears.
3. If the failure keeps coming back in one session: start a brand-new session in the same project (not --continue or --resume) → expect: a commenter said Bash then works from the first call, but the failure returned after a while in their setup.
4. Not confirmed in the thread: a commenter, citing Anthropic's docs, said starting Claude Code with the environment variable CLAUDE_CODE_AUTO_MODE_SERVER=0 (v2.1.281 or later, direct Anthropic API connection) makes the client send its own classifier requests instead of using the server; it is read at startup, so begin a new session → expect: /status in auto mode shows "Auto mode server: Disabled" (per that commenter; nobody reported trying it).

How to verify

In auto mode, ask Claude to run echo ok → expect: it runs and prints ok with no "no verdict" error.

What did not work

Retrying or waiting inside the same session did not clear the repeating version for one commenter. One commenter said switching the model from Opus 5.5 to Opus 5 made auto mode work again, but another said Opus 5.5 worked again for them around the same time, so the service may simply have recovered (our inference).

Rollback

Switch the session back to auto mode. If you set CLAUDE_CODE_AUTO_MODE_SERVER=0, remove it and start a new session.

Risks

In the default and Accept Edits modes Claude asks before running commands, which a commenter found intrusive; approve each one deliberately. Do not switch to a mode that skips permission checks altogether just to get past this outage (our inference). Per the docs the commenter quoted, with CLAUDE_CODE_AUTO_MODE_SERVER=0 the classifier requests count toward token usage on Enterprise plans, Claude API keys and cloud providers, and the variable is described as temporary. Commenters linked their own command-gate and transcript tools installed with npx; we have not reviewed them, so don't install them without checking what they do (our inference).

Verified scope

Claude Code 2.1.28x in auto mode, September to October 2026.

Becomes obsolete when

Auto mode falls back to a normal permission prompt when the check gives no verdict, or the service stops dropping verdicts. Open question: whether the repeating case on third-party model endpoints has a separate cause; nobody in the thread confirmed one.