AI operations · Sources checked November 7, 2026
An automated coding job can stop waiting for approval and still leave important work undone. Claude Code 2.1.319 makes that distinction worth reviewing, especially for teams running unattended jobs through an LLM gateway.
The new release changes the refusal path
Anthropic’s November 6 release changes the default auto-mode behavior when telemetry or feature-flag fetching is off: an action the server cannot review is prompted for or denied, rather than falling back to the built-in classifier. The release explicitly leaves Bedrock, Vertex and Foundry unchanged for this change. It also documents an explicit CLAUDE_CODE_AUTO_MODE_SERVER=0 option to retain the built-in classifier; choosing that review path is a separate policy decision.
It also fixes a specific reporting problem: a noninteractive claude -p run in auto mode that refused actions because no safety check was available now exits with status 1 in text and JSON output, rather than 0. A new permissions.denyInsteadOfPrompting setting denies calls that would wait for approval and lets the turn continue in terminal sessions, subagents and teammates.
Those are vendor-documented changes. We have not installed or tested this release. Our 2.1.318 article focused on prompt input and saved configuration. The separate question here is how an automation records a refusal and decides whether the requested job is complete.
Define completion before changing the runner
Consider a fictional nightly task that reviews a dependency update, runs a small test suite and writes a report. Reading the change may work while the test command is refused. A report can still be produced. Unless the surrounding workflow checks that the required tests actually ran, a finished conversation could be mistaken for a finished review.
Write down the required outcomes before the upgrade: the exact test suite, the expected report and the evidence that connects them to this run. Treat a missing test result as incomplete work. A readable explanation of why a command was blocked is useful, but it should not qualify the update for automatic promotion.
Keep three fields separate in the job record: process exit status, refused or skipped required steps, and validation of the expected output. Anthropic’s noninteractive-run documentation explains exit-status handling and warns that structured output can be absent. Check the result you need before another system consumes it.
Review the effective environment
Make a short inventory of the executable version, permission mode, provider or gateway, telemetry and feature-flag settings, and the source of managed policy. Record setting names and non-secret values only. The settings guide explains scope and precedence; a setting on a developer’s workstation is not proof of what a runner received.
Do not treat a new refusal as a reason to weaken review automatically. First identify the required operation, the rule or unavailable review path that stopped it, and who owns the intended policy. An approved narrow permission change and a deliberate choice of review architecture deserve their own decisions. Neither should be hidden inside a fix for a red build.
The exit-code fix is narrowly described. It does not establish that every possible denied action must terminate every session with status 1. Likewise, allowing a turn to continue after denying a call does not make that call optional for your business workflow.
Use three harmless staging cases
- Required work succeeds. Use a disposable repository and a small task whose output can be checked independently. Verify both the output and the wrapper’s success decision.
- A required action is deliberately denied. With a harmless test operation and an explicit rule, confirm that the operation did not occur and that the wrapper marks the job incomplete. Do not rely only on the assistant’s final prose.
- The review path is unavailable. In an approved staging setup matching the relevant gateway and flag settings, observe the refusal, result and process status. Verify that the pipeline stops before publishing or promoting the output. This is a proposed check, not a claim that we reproduced the behavior.
Keep the evidence small: version, configuration source, expected outcome, observed action, exit status and next owner. Expand the rollout only when the wrapper distinguishes a completed task from a safely blocked one. That distinction makes a refusal an actionable operational result instead of an unexplained missing step.