Claude Code 2.1.319 changes auto mode when telemetry is off, and claude -p now exits 1

Claude Code 2.1.319, dated 6 November 2026 in Anthropic's changelog, changes what auto mode does when it cannot reach its server-side safety check. Where it previously fell back to a built-in classifier, calls the server cannot check are now asked about or denied. If you run auto mode with telemetry off, with feature-flag fetching off, or behind an LLM gateway, set CLAUDE_CODE_AUTO_MODE_SERVER=0 to keep the old behaviour, and expect claude -p to exit 1 where it used to exit 0.

Those two items are the ones to read before upgrading. The rest of the release is large, and most of it is additions and fixes that change nothing you depend on.

#What exactly changed in auto mode?

The changelog entry is worth quoting, because it names both the trigger and the escape hatch:

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; set CLAUDE_CODE_AUTO_MODE_SERVER=0 to keep using it (Bedrock, Vertex and Foundry are unchanged)

Three conditions reach this: telemetry off, feature-flag fetching off, or running behind an LLM gateway. In any of them, auto mode previously had a local classifier to fall back on. Now it does not, so a tool call the server cannot vet becomes a prompt or a refusal.

The parenthesis matters as much as the sentence. Amazon Bedrock, Google Vertex and Microsoft Foundry are called out as unchanged, so a deployment on one of those three is not affected by this item.

A second entry covers the gateway case from the other direction:

Changed auto mode behind an LLM gateway: CLAUDE_CODE_AUTO_MODE_SERVER=1 turns on the server-side check even with CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS set; if managed settings set the latter, they must set the 1 too

That is a note for anyone administering Claude Code through managed settings. If your managed settings disable experimental betas and you want the server-side check, the same settings now have to set CLAUDE_CODE_AUTO_MODE_SERVER=1 explicitly.

#Why does this break a passing CI pipeline?

Because of a change filed as a fix rather than a behaviour change:

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

Read together with the auto mode change above, this is the item most likely to surprise someone. The two interact: the first makes refusals more likely when the server check is unreachable, and the second makes those refusals visible to whatever is reading the exit code.

The direction is right. A run that refused to do its work and reported success was the worse of the two behaviours. But it means a pipeline that has been green may go red on upgrade without anything else changing, and the cause is a refusal that was already happening silently.

A related entry moves another case to the same exit code:

Fixed claude -p --resume with a prompt losing a deferred tool call when its MCP server is missing: the run now exits 1, keeps the call and refuses later input

#Which deployments need to do something?

Deployment	Auto mode change applies	What to do before upgrading
Claude API, telemetry and feature flags on	No	Nothing
Claude API with DISABLE_TELEMETRY set	Yes	Set CLAUDE_CODE_AUTO_MODE_SERVER=0, or accept prompts and denials
Behind an LLM gateway	Yes	Set CLAUDE_CODE_AUTO_MODE_SERVER=0 to keep the classifier, or =1 in managed settings to use the server check
Amazon Bedrock, Google Vertex, Microsoft Foundry	No	Nothing for this item
Any scripted claude -p run in auto mode	Exit code only	Check whether the job was passing on refusals that exited 0

#Can a repository turn the server-side check back on?

No, and this is a tightening worth knowing about:

Changed auto mode so that a project's settings files or a plugin can no longer switch its server-side check back on once you have switched it off outside the project

Before this, a setting you made at user or machine level could be overridden from inside a project. The switch now only moves in one direction from where you set it, which means cloning a repository cannot quietly re-enable the server-side check for you. If you rely on a project's settings to turn it on, that no longer works and the setting has to move outside the project.

#What else is in 2.1.319?

A few additions stand out for anyone running Claude Code unattended:

• permissions.denyInsteadOfPrompting. A tool call that would wait on a permission prompt is denied and the turn continues, in terminal sessions, subagents and teammates. For a scheduled job that should never stall on a prompt, this is a more honest setting than a wide allowlist.
• MCP tasks in the terminal. When an MCP server runs a tool call as a task, Claude Code now moves it to the background immediately and reports the result when it finishes. CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND makes it wait inside the tool call instead, and the changelog adds that MCP tasks now work in the terminal without feature-flag fetching, with CLAUDE_CODE_DISABLE_MCP_TASKS=1 to turn them off.
• CLAUDE_CODE_DISABLE_FEATURE_FLAGS. Stops feature-flag fetching without turning off telemetry, with every flag falling back to its built-in default. Note that turning flags off is one of the conditions that triggers the auto mode change above.
• A /status fix. /status used to report Auto mode server: Enabled when the server-side review was not actually reaching the session, for example behind a gateway that drops it. If you checked /status on an older build and concluded the server check was running, check again.

There is also a dated item for administrators: the release adds start-up warnings to the Claude apps gateway for policies with no desktopHome that rely on coworkTabEnabled: false or chatSessionRetentionDays, which the changelog describes as being ahead of a Claude Desktop change on 10 November. If you administer a gateway, that warning is worth reading before then rather than after.

#What should you check before upgrading?

1. Do you set DISABLE_TELEMETRY, disable feature flags, or run behind an LLM gateway? If yes, decide between CLAUDE_CODE_AUTO_MODE_SERVER=0 and living with more prompts and denials.
2. Do any scripted runs use claude -p with auto mode? Look at whether they have been exiting 0 while refusing work.
3. Do your managed settings set CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS? If you want the server-side check, add CLAUDE_CODE_AUTO_MODE_SERVER=1 alongside it.
4. Does any project's settings file turn the server-side check on? That no longer takes effect if you switched it off outside the project.

For the permission model these settings sit inside, our security hardening guide covers the allowlist and deny-rule shape in more detail. The previous release we covered, Claude Code 2.1.316, retires fast mode on Opus 4.8 on 30 November 2026, which is a separate deadline on the same upgrade path. Background on the platform is on our Claude Code hub.

Versions 2.1.317 and 2.1.318, dated 3 and 4 November 2026, landed between our last coverage and this release, and two entries in 2.1.317 matter if you are moving straight from 2.1.316. It moved another claude -p case from exit 0 to exit 1, when a full disk or quota lost its transcript or ~/.claude.json writes, with the changelog adding that "Full NFS exports may be missed". It also fixed auto mode "failing every turn when an LLM gateway set as the base URL answers 403 or 422 to its server-side safety check", noting that a 403 with an apiKeyHelper is unchanged. So gateway behaviour in auto mode has moved twice inside four days, and 2.1.319 is the release that removes the local fallback. From 2.1.318, the item in the same area is a timing change: with telemetry off, or on Bedrock, Vertex and Foundry, a subagent progress summary on a cold prompt cache can now wait up to five minutes for the subagent's pending response.