Independent AI intelligence Two editions daily · ET
Fervor AI

Analysis · November 6, 2026 · concept

Claude CodeAnthropicclaude-codeagent-securityagent-harness

Claude Code's Auto Mode Now Treats a Missing Safety Check as a No

Version 2.1.319 stopped swapping in a backup reviewer for some sessions. Here is how to tell which reviewer you have, and what to do with prompts nobody will answer.

Every permission system has a question nobody asks until the day it matters: what happens when the checker isn't there?

For coding agents that question used to have a soft answer. If the thing that reviews risky actions couldn't be reached, the tool found another way to keep going. Claude Code just changed that answer for a specific, common setup, and the change landed in a release note before it landed in the manual.

The result is simple to state. In version 2.1.319, for sessions running with telemetry (usage reporting back to Anthropic) or feature flags (remote switches that turn features on and off) disabled, including sessions behind an LLM gateway, an action the server can't check is now asked about or refused. It no longer falls back to a local reviewer. If your team routes Claude Code through a corporate proxy, you are probably in that group, and your agent is about to stop more often.

That is the right trade. It also deserves a deliberate decision from you instead of a surprise on Monday.

First, what auto mode actually does

Claude Code is Anthropic's coding agent for the terminal and editor. It reads your repo, edits files and runs shell commands. Before each risky step it needs a yes from somebody.

In the default mode that somebody is you, clicking through prompts. Auto mode hands the job to a second model. The docs put it plainly: "In auto mode, a second model, the classifier, reviews actions instead of you." Think of it as a bouncer standing between the agent and your shell. Reads, searches and edits inside your working folder go straight through. Everything else, like a shell command or a network call, gets looked at first, and the bouncer blocks anything that "escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read," per the permission modes page.

This matters more than it used to. Since version 2.1.283, auto mode is the built-in starting mode for interactive terminal and VS Code sessions, according to the same page. Plenty of people are running it without ever having chosen it.

There are two possible bouncers. Claude Code can send its own review request to a model (by default, the docs say, Claude Sonnet 5), or it can ask Anthropic's server to review the action. That second path is called server-side classifier review, and a session that doesn't fetch feature flags (for example, because you turned telemetry off) asks the server by default, per the docs.

What changed in 2.1.319

Version 2.1.319 went up on npm at 7:58 pm ET on November 5 (registry), and when I read the registry on the afternoon of November 6 it carried both the latest and next tags. The changelog entry reads: "Changed auto mode with telemetry or feature flags off, including behind LLM gateways": calls "the server can't check are asked about or denied, with no fallback to the built-in classifier."

In plain words: before, if the server couldn't review an action, Claude Code would send the action to its own local reviewer and carry on. Now, for this group of sessions, a missing review means a prompt in an interactive terminal or a refusal where nobody is there to answer.

Three details keep this from being bigger than it is:

  • It covers sessions with telemetry or feature flags off, which includes many gateway setups. Bedrock, Vertex and Foundry are unchanged, the changelog says.
  • There is an escape hatch. Setting CLAUDE_CODE_AUTO_MODE_SERVER=0 keeps the old local reviewer.
  • Headless runs (scripts and CI jobs with no person at the keyboard) now tell you. The changelog says claude -p exits with code 1 in auto mode when its actions were refused because no safety check was available.

One more line is easy to miss and matters for shared repos. A project's settings files or a plugin can no longer switch the server check back on once you turned it off outside the project. Your choice on your machine stays your choice.

Why gateways are where this bites

An LLM gateway is a proxy many companies put between their developers and the model provider, to log usage, enforce budgets or route traffic. It is a sensible piece of plumbing. It is also exactly where server review tends to vanish.

The docs list the common reason the server doesn't review a session: "an LLM gateway or proxy that drops the request for review or the results." The errors page goes further. When the server gives no verdict, the action is denied, and after ten responses in a row with no verdict, Claude stops the turn. One of the listed fixes is to check that your gateway "isn't cutting off or rewriting streaming responses."

So picture the usual path. A platform team sets up a proxy, turns telemetry off for privacy reasons, and rolls out Claude Code. Review requests die in the proxy without a sound. Until now, the local reviewer picked up the slack and nobody noticed. From 2.1.319 on, developers on that setup get prompts and refusals, and the cause sits three teams away in a proxy config.

There was a lying-dashboard problem too. The same release fixes /status showing "Auto mode server: Enabled" when the server review wasn't actually reaching the session. If you checked once and saw "Enabled," check again on the new version.

The manual hasn't caught up

Reading the changelog against the docs this afternoon, the two disagree. The permission modes page still says that when the server doesn't review the session, "Claude Code falls back to its own classifier requests."

For some sessions that is still true. For sessions with telemetry or flags off, the changelog says it is not. When a release note and the manual disagree, trust the release note for the version it describes and expect the docs to follow. Just don't build a runbook on the manual's sentence this week.

The three fixes that make upgrading worth it anyway

The fail-closed change would be easy to resent if it came alone. It didn't. The same release closes three holes in the permission system, all from the changelog:

  • "a Bash permission bypass where a crafted environment prefix could hide part of a command from permission checks"
  • "a sandbox escape when creating a worktree"
  • "a case where a sed command could skip the permission check in accept-edits and auto mode"

The first one is the kind of bug a prompt-injection payload would go looking for: dress up a command so the checker reads one thing and the shell runs another. The stable channel is still on 2.1.311 per npm, so anyone pinned there doesn't have these fixes yet.

Put this into practice

Five steps, roughly in the order you'd do them on a Monday morning.

1. Check your version. Run:

claude --version

If it says 2.1.319 or later, the new behavior can apply to you, but only when telemetry or feature-flag fetching is off (gateway setups often are). Bedrock, Vertex and Foundry are unchanged. If it says 2.1.311, you're on stable and won't see the change (or the three fixes) until that channel moves.

2. Find out which reviewer you have. Inside a session, run /status and look for the Auto mode server line. "Enabled" means the server is set to review this session's calls. If it says "Enabled" but you keep hitting "no safety verdict" errors, suspect the gateway first.

3. Decide between fail-closed and the local reviewer. You have two honest options:

  • Keep the new behavior and fix the gateway so review requests and their streamed results pass through untouched. This is my default recommendation: leave fail-closed on unless you have a specific reason not to.
  • Bring the local reviewer back while you sort the proxy out:
export CLAUDE_CODE_AUTO_MODE_SERVER=0
claude

Know what the second option costs. The docs note that on accounts where local classifier requests are billed, Claude Code shows a notice about those charges (billing page). You're paying for your own bouncer.

4. Decide what an unanswered prompt means in unattended jobs. A permission prompt in a job nobody is watching is a silent hang. Version 2.1.319 adds permissions.denyInsteadOfPrompting: "a tool call that would wait on a permission prompt is denied and the turn continues," in terminal sessions, subagents and teammates. The changelog names the key, but the settings reference didn't document it when I checked, so the nested settings-file form below is my reading of the dotted key, not documented syntax. Test it on a scratch repo before you depend on it:

{
  "permissions": {
    "denyInsteadOfPrompting": true
  }
}

A refused step is still a skipped step. Pair it with a check in your job that reads the agent's output for refusals, so "finished" doesn't secretly mean "finished the easy parts."

5. Handle the new exit code in CI. If you run claude -p in a pipeline with auto mode, a refusal caused by a missing safety check now exits with code 1. Make sure your pipeline fails loudly on it instead of retrying in a loop.

Honest limitations

This change is narrow, and it's fair to say so. It covers sessions with telemetry or feature flags off. Many developers on a direct Anthropic connection with defaults won't notice anything.

The evidence is thin in places. The behavior is documented in a changelog line, and the official docs still describe the older fallback. denyInsteadOfPrompting has no docs page yet. If you hit something that contradicts this article, the changelog for your exact version wins over anything written here.

Fail-closed also has a real cost. More prompts mean more interruptions, and the person most likely to flip CLAUDE_CODE_AUTO_MODE_SERVER=0 is a tired developer on a Friday evening, not a platform team making a considered call. A safety default only works if the escape hatch is a decision, not a reflex.

And none of this makes auto mode a sandbox. A classifier is a second opinion on intent. It doesn't stop a command it approves from doing damage, which is why the three permission fixes in the same release matter as much as the headline change.

What to do with this

The interesting part of this release isn't any single flag. It's the default it picked. When nobody can vouch for an agent's next move, Claude Code now stops instead of improvising, at least for the sessions where the gap is most likely to go unnoticed.

You can live with that default, or you can turn it off. Either way, run /status before Monday, look at what your proxy does to review traffic, and make the choice yourself. The worst outcome is the one most teams will drift into: a bouncer they never checked on, at a door they forgot they had.

Sources: Claude Code CHANGELOG, 2.1.317 to 2.1.319; npm registry for @anthropic-ai/claude-code (2.1.319 published 2026-11-06T00:58Z, dist-tags read November 6); Permission modes docs; Errors docs; Permissions docs. Reviewed against version 2.1.319.