Coding with AI

Claude Code Changes How Unattended Jobs Fail

Claude Code 2.1.319 changes auto-mode refusals, exit codes and MCP task handling. Check what your scheduled jobs actually finish before relying on them.

Two illuminated status indicators beside a tray of blank paper, illustrating a completed unattended job and a separate permission decision.

On November 6, 2026, Anthropic released Claude Code 2.1.319 with a specific fix for unattended runs: when claude -p refuses auto-mode actions because no safety check is available, it now exits with status 1 instead of 0, for both text and JSON output. The same release notes also change what happens when auto mode cannot check an action and add a way to deny a permission prompt while the turn continues. If a scheduler treats exit status alone as proof that work finished, verify the output artifact as well.

What changes for unattended runs

The release touches three different checkpoints in a job: whether an action is allowed, whether Claude Code keeps working after a denied action, and what the process reports when it exits. Those checkpoints should not be folded into one “success” signal. This table describes only the cases Anthropic documents in version 2.1.319; it is not a result from our own run.

Case Earlier behavior stated by Anthropic Behavior in 2.1.319 What to check
claude -p auto-mode actions refused because no safety check is available Exit status 0, including text and JSON output Exit status 1 Capture the return code and the refusal in output
Auto mode with telemetry or feature flags off, including some LLM-gateway setups Built-in classifier could be the fallback Calls the server cannot check are asked about or denied, with no classifier fallback Check the gateway and managed settings before scheduling
A tool call that would wait for a permission prompt, with permissions.denyInsteadOfPrompting set Release does not specify the earlier behavior of this new setting The call is denied and the turn continues, including in terminal sessions, subagents and teammates Check which action was denied and what the final artifact contains
An MCP server runs a tool call as a task in the terminal Release does not fully specify prior task handling Claude Code moves it to the background immediately and reports its result when complete Confirm the task’s result reaches the job before accepting its output

The exit-code fix is narrow. It does not say every denied action now exits 1. Likewise, a continuing turn after a denied tool call does not prove the requested work succeeded. Anthropic’s permissions guide describes rule order as deny, then ask, then allow; a rule can prevent one action without deciding whether the rest of a task is useful.

A denied action is not the same as a failed process

permissions.denyInsteadOfPrompting is useful when a terminal job cannot wait for a person to answer a permission prompt. The documented behavior is to deny the tool call and let the turn continue. An agent might then finish other permitted steps or explain what it could not do. That is different from the documented claude -p correction: status 1 applies when auto-mode actions are refused because no safety check was available. Both claims come from Anthropic’s release notes, and neither tells us how a particular workflow will behave without testing that workflow.

For a scheduled job, define success in terms of the intended result. A code maintenance task might require a changed file, a passing check and a final report that names the file. A research task might require a non-empty saved report with its source links. Those are illustrative acceptance checks, not tests we ran. Capture the process exit code, but also inspect the output and any generated file. A status 0 with a missing deliverable is still a failed business outcome; a denied optional action might leave a useful partial result that needs human review.

This distinction matters most for jobs that span tools. If an MCP tool starts a background task, the release says Claude Code will report its result when that task completes. It also adds CLAUDE_CODE_DISABLE_MCP_TASK_BACKGROUND to make the tool call wait instead. The notes do not promise a speed gain or guarantee that every external task completes. Check the final result, rather than treating “started” as “finished.”

Check your gateway and managed settings

The auto-mode change affects setups where telemetry or feature flags are off, including some deployments behind LLM gateways. In 2.1.319, a call that the server cannot check is asked about or denied instead of falling back to the built-in classifier. Anthropic explicitly says Bedrock, Vertex and Foundry are unchanged in this case. That means a gateway operator should check their own configuration; the release does not say every gateway is affected.

Two documented switches need careful reading. CLAUDE_CODE_AUTO_MODE_SERVER=0 keeps using the built-in classifier. Behind an LLM gateway, CLAUDE_CODE_AUTO_MODE_SERVER=1 turns on the server-side check even if CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS is set. If managed settings set the latter, Anthropic says they must also set the 1 value for that server-side behavior. These are descriptions of release-note controls, not a recommendation to relax a safety policy. Record the effective organization settings before changing a schedule, and ask the administrator which review path is intended.

The release also adds a warning when a claude.ai login ends and Claude Code continues using credentials from ant auth login; that usage bills the Claude Console organization. A new startup line names that organization in the documented case. If an unattended job can change authentication context, verify the billed organization before interpreting its cost. This release does not state a new token price. For a separate workload estimate, use the site’s API cost calculator with your own usage figures; it cannot verify which organization a particular run actually billed.

Verify one job before upgrading the schedule

The following is a proposed validation checklist, not a report of tests performed. Run it on a representative job with a safe, read-only task and preserve the output for comparison.

  1. Record claude --version, the permission mode, relevant environment variables and managed settings. Keep secrets out of the log.
  2. Run a permitted read-only request and confirm that its expected file or report exists and contains the requested information. Store the exit code and text or JSON output alongside it.
  3. In a controlled test, include an action your permission policy should deny. Check the denial message, whether the turn continues, and whether the final artifact accurately states what was skipped. Do not assume this is the same as the unavailable-safety-check exit-1 case.
  4. If the job uses an MCP task, observe its completion result before accepting the artifact. Compare the normal background behavior with the documented waiting switch only if that comparison fits your deployment.
  5. If a gateway or alternate sign-in is involved, confirm which organization is billed and whether the server-side review path is active. Recheck after any managed-settings change.
  6. Only then update the scheduler’s success rule. Require the deliverable and any job-specific validation, with exit status as one signal.

This release concerns the Claude Code client and its execution path, not a new Claude model. The DailyTech model tracker is useful for model releases; it does not answer whether a local permission decision or MCP task finished. For adjacent operational questions, our sandbox cost guide covers retained resources after a session, while the Claude IP allowlist guide covers network egress. Neither replaces a check of this version’s process and artifact behavior.

Sources

All pages read on November 9, 2026.

Free toolWhat will 10,000 chats a month cost?Estimate my bill
DailyTech Editorial Team

We explain AI with numbers you can check. Every price, limit and benchmark links to its source and the date we read it. How we work · Report an error