Claude Code Auto Mode 'Gave No Verdict': Why Even pwd Gets Blocked

If Claude Code suddenly refuses every shell command — even pwd — with this, you're not alone:

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.

Starting on 28 September, three separate GitHub reports filed the same day collected dozens of "same here" replies across macOS, Linux, Windows and WSL, in the terminal, VS Code and the desktop app. The top one, #97854, describes every Bash call failing for several minutes, then recovering with nothing changed. Users kept reporting it on 29 and 30 September and into October.

The short version: your command was never judged. A safety check that runs before risky actions failed to answer — the auto mode classifier gave no verdict — and the CLI chose to block rather than run anything unchecked. Below is what that check is, why the failure looks so strange, and the four ways out.

What auto mode's classifier actually does

In auto mode, the CLI stops asking you to approve each action. Instead, as Anthropic's docs put it, "a separate classifier model reviews actions before they run, blocking anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read."

From v2.1.283, auto mode is the default starting mode for interactive terminal and VS Code sessions. That's why so many people met this error without ever choosing auto mode.

The detail that matters for this error is where the check runs. Recent versions ask Anthropic's servers to do it as part of the normal model request, instead of Claude Code making a separate classifier call. The docs call this server-side classifier review, and it's being rolled out across the direct Anthropic API, cloud providers and LLM gateways.

When the server returns its decision, that decision is final. When it returns nothing, the classifier gave no verdict, and the action is refused.

Why pwd is blocked but Read still works

This is the part that makes the error feel broken. Claude can still read your files, search the code and often edit, but ls fails.

It's by design. In auto mode's decision order:

The docs are explicit that "in a session with server-side classifier review, read-only and sandboxed shell commands wait for that review." So when the review fails, every Bash call fails with it, harmless or not. The Read tool, which never goes to the check, carries on.

If your file edits are blocked too, which two of the reports describe, check two things. Is the file outside the directory you started the session in? And is it under a protected path such as .claude/, .git/, .vscode/ or .mcp.json? Both of those always go to the check in auto mode.

The three messages, and what each means

One action blocked:

The server-side auto mode classifier gave no verdict (timed out), so auto mode
cannot determine the safety of <tool>.

The word in brackets is the failure category, when one can be worked out — (timed out), (error) and so on. Before some retries, it waits; the spinner shows Auto mode check unavailable with a countdown, and Esc interrupts.

The turn stopped:

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.

Ten responses in a row without a verdict ends the turn. In a non-interactive -p run, the run ends with an execution error. A subagent that hits the limit stops early, and the main session gets whatever it produced.

A different failure that looks similar:

<model> is temporarily unavailable (rate-limited), so auto mode cannot determine
the safety of <tool> right now. Wait a moment and then try this action again.

This one comes from Claude Code's own classifier request rather than the server's review. The category can be (rate-limited), (overloaded), (server error), (timed out) or (connection failed). If timed out or connection failed keeps coming back, treat it as a network problem first — it's the same territory as 529 overloaded errors.

Four fixes, in the order I'd try them

1. Send another message

The official first step, and often enough. Sending a new message resets the count of failed responses. In the reports, most outages cleared on their own within minutes to tens of minutes. One commenter put a window of roughly 13:16–13:35 UTC on 28 September.

If you can, keep Claude busy with read-only work meanwhile. Reading and searching don't need the check.

2. Use Claude Code's own classifier instead of the server's

export CLAUDE_CODE_AUTO_MODE_SERVER=0
claude

This tells the CLI to skip the server-side review and make its own classifier requests, the way it did before. It's documented, and a commenter on #97766 reported it as an effective workaround during the outage. Set it before starting the session, in your shell or in the env block of your settings file.

Three things to know first:

• It needs v2.1.281 or later on a direct Anthropic API connection. Earlier versions ignore it there.
• It can cost money, depending on your account. The server's checks are free. Claude Code's own classifier requests count toward token usage on Enterprise plans, Claude API accounts, and Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry.
• It's temporary. Anthropic's billing page says the variable "is a temporary setting and may be removed in a later release." Use it to get through an outage, not as permanent config.

To see which path a session is on, run /status. The Auto mode server row reads Enabled while the server is doing the checks, and Disabled once the session has fallen back to its own.

3. Switch out of auto mode

Press Shift+Tab to change permission mode. This was the most common workaround in the threads, and the one Anthropic's message itself suggests:

• Manual (default) — you approve everything except reads. Slower, but immune to this error.
• Accept edits — file edits and common filesystem commands like mkdir, mv and cp run automatically. Other shell commands still ask you.

Several people reported switching to accept-edits for a few actions and then back to auto as a fix. That probably just coincided with the server recovering — there's no documented reason it would reset anything. But it's harmless.

4. If it never stops: check your gateway or proxy

If your traffic goes through an LLM gateway or company proxy (ANTHROPIC_BASE_URL points somewhere other than Anthropic), and the error keeps coming back when nobody else is reporting an outage, the gateway is the likely cause.

The docs name the behaviour precisely. A gateway that cuts streaming responses short, or rewrites them, means the safety results never arrive intact. The client then sees no verdict and blocks the action. The fix is on the gateway side: pass requests and responses through unchanged, including fields it doesn't recognise, such as safeguards on requests and safeguard_results on responses.

If you know your gateway can't do that, CLAUDE_CODE_AUTO_MODE_SERVER=0 is the documented setting for exactly this situation.

Why it blocks instead of asking you

The most-repeated request in the threads is the same one: if the check is down, fall back to asking me, don't refuse. It's a fair complaint. A blocked turn burns time, and one user pointed out that each failed attempt still spends a turn against their usage.

Claude Code's current behaviour is a deliberate fail-closed design. Its docs say it "denies the action rather than run it unreviewed." Anthropic doesn't spell out the reasoning there, but my reading is this: auto mode exists for people who aren't watching each action. Quietly downgrading to "ask" could just as easily mean an action sits waiting while nobody is there, or, in a non-interactive run, gets dropped without a decision.

You don't have to accept that default. The fixes above are the ways to choose a different trade-off for your own session.

The bigger picture: a check on every tool call is now a product category

This outage is a good example of something every agent builder will run into. Once a second model sits between the agent and every risky action, that model's uptime becomes your agent's uptime.

That pattern has just become its own kind of product. On 15 September, TypeSafe AI released Jev, a "decision model" that doesn't write text at all. You send it the current state and a set of typed questions, and it returns choices with probabilities, in tens to hundreds of milliseconds. LangChain's walkthrough uses it for precisely this job: classifying risky tool calls before they're taken, alongside a normal LLM doing the actual work.

Two cautions if you're tempted. Jev is in limited early access, and its headline claims — 40 to 200 times faster and 40 to 400 times cheaper than frontier models — are the company's own. Wikipedia notes that TypeSafe itself describes those figures as likely to sit at the high end of real-world results.

More importantly, a faster checker doesn't remove the problem this post is about. It moves it. Whatever you put in front of your tool calls, decide up front what happens when it doesn't answer — block, ask a human, or allow — and make that choice visible to the people running the agent. Claude Code made its choice and documented it. Most homegrown agent harnesses haven't made one at all.

Quick triage

1. Is Read still working? Then the agent is fine and only the safety check is failing.
2. Send another message. It resets the counter, and short outages clear on their own.
3. Still failing? Restart with CLAUDE_CODE_AUTO_MODE_SERVER=0 (v2.1.281+), knowing it may bill classifier calls on API, Enterprise and cloud-provider accounts.
4. Need to keep moving right now? Shift+Tab out of auto mode and approve actions yourself.
5. Happens constantly, and only for you? Check whether a gateway or proxy is truncating streamed responses.

If the gateway in step 5 is a company proxy, the same "something in the middle rewrote the traffic" problem is behind Claude Code's corporate-proxy SSL errors. Deciding what an agent is allowed to do unsupervised, and what happens when the guardrail itself goes down, is a large part of the agent work I do — see recent projects.