• Claude Code 2.1.319, released 6 November, runs auto mode's safety check as a field on your normal inference request. I captured the traffic. Each agentic turn carries a safeguards block, and the verdict comes back inside the same response's message_delta, not from a separate classifier call.
  • That block ships the server your working directory, your home directory, and the exact command that launched Claude Code. The side requests, session titles and status summaries, carry none of it.
  • The same release stopped auto mode from falling back to the built-in classifier when telemetry or feature flags are off, including behind an LLM gateway. If your proxy buffers or rewrites the stream, the action is denied, and claude -p now exits 1 where it used to exit 0.

Auto mode is the permission mode that lets Claude Code act without stopping to ask you each time. A classifier decides whether a given tool call is safe. Until this week I pictured that as a separate request off to the side. It isn't, at least not on a direct connection to the Anthropic API. I pointed Claude Code 2.1.319 at a local proxy that logs every request body and forwards it unchanged, ran one trivial task in auto mode, and read what went over the wire.

What the request actually carries

The task was "create a file named hello.txt." Claude Code sent three requests. The first two were the agent's own turns. Each one carried a safeguards field next to the usual model, messages and tools:

"safeguards": [{"type": "dangerous_tool_use",
  "classifier_context": {"v": 1, "permission_mode": "auto",
    "platform": "macos", "live_cwd": "...", "home_dir": "...",
    "rule_roots": {...}, "command": "..."}}]

The anthropic-beta header named dangerous-tool-use-2026-09-03. That makes the safety review a beta feature folded into the main call, not a round trip of its own.

The verdict came back in the response, in the message_delta event that closes the turn:

"safeguard_results": [{"type": "dangerous_tool_use",
  "status": {"type": "available",
    "tool_uses": {"toolu_01Qk...": {"type": "skipped"}}}}]

skipped means the Write was not flagged. The model proposed a tool call, and the server's answer about that call arrived in the same response that proposed it. The third request, a short status summary with no tools, carried no safeguards field at all. The check attaches to turns that can act, and skips the side chatter.

It sees your command line

The interesting part of classifier_context is what it holds. live_cwd is the directory Claude Code is running in. home_dir is your home path. command is the full argument list that launched the process. rule_roots points at every settings file in play: user, project, local, policy. None of that is secret, and it is the context a classifier needs to judge whether a path is reasonable to write. Still, the safety check reads your working directory and your launch command, which is more than most people picture the classifier seeing.

The fallback is gone when the server can't answer

One change in the release matters more than the rest for anyone running Claude Code unattended. The 2.1.319 changelog gives it one line:

"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."

Before this, a session that couldn't reach the server-side check would quietly fall back to the client-side classifier, a separate billed request. Now it doesn't. If the server returns no verdict for an action, Claude Code denies the action rather than run it unreviewed. The docs name the usual cause plainly: "an LLM gateway or proxy that cuts responses short or rewrites the results."

Picture what a well-meaning gateway does. It might buffer the stream to inspect it, collapse events, or strip fields it doesn't recognise. The safeguard_results block lives in the final message_delta. Drop it, reorder it, or hold the whole response until it completes, and Claude Code sees a turn with no verdict for the tool call it just proposed. In auto mode, that is a denial.

The second line is the one that will catch a CI pipeline:

"Fixed claude -p exiting 0 in auto mode when its actions were refused because no safety check was available: text and JSON output now exit 1."

A headless run that used to finish green while silently skipping the blocked step now exits non-zero. That is the correct behavior. It is also a behavior change that lands on 6 November, in a point release, in a tool that updates itself.

What to do about it

If you run Claude Code in auto mode behind a gateway, the gateway has to relay each response's full event sequence, in order, through the closing message_delta and message_stop. The gateway protocol docs say this outright. A gateway that buffers responses or rewrites them is now the thing standing between Claude and its own safety verdict.

If you would rather not depend on the server-side check, CLAUDE_CODE_AUTO_MODE_SERVER=0 goes back to the local classifier, which runs as separate requests and shows up on your bill on accounts where those are metered. On a direct Anthropic connection that variable needs 2.1.281 or later.

The thing to internalise is that the safety decision now rides on the same wire as the work. It is not a sidecar you can lose without noticing. In 2.1.319, losing it means the work stops, and your exit code finally tells you so.