# Claude Code Now Fails Loudly When Automated Runs Break > Claude Code 2.1.314 and 2.1.317 fix automated claude -p runs that exited 0 after failing. What changed, why it matters to your team, and what to check. Canonical: https://bridge-terminal.com/atlas/blog/claude-code-automated-runs-exit-code-failures/ Last updated: 2026-11-04 Published 4 November 2026 · Plain English · What's new · 5 min read ## The short version - Two Claude Code releases, 2.1.314 (30 October 2026) and 2.1.317 (3 November 2026), fixed cases where an automated run ended with a success signal after it had failed. - 2.1.314 fixes a run that failed at startup and said nothing; 2.1.317 fixes a run that could not save its own records because the disk or quota was full. Both now print an error and exit 1. - If you run Claude Code on a schedule or in a build pipeline, update: a green tick that hides a failed run is worse than a red one. - Treat a success signal as a claim, not proof. Also check that the expected file, change or report actually exists. - Atlas refuses to call work done until the result is on main (or queued to land), screens have test cases and screenshots, and the product's rules pass. Reading Claude Code's exit signals is not something it does today. If your team runs Claude Code automatically, for example on a schedule or inside a build pipeline, it now tells you more reliably when it has failed. Two recent releases fixed cases where an automated run ended with a "success" signal even though nothing useful had happened. Here is what changed, what it means for a team, and what to check. ## What changed in Claude Code, and when? Claude Code can run without a person at the keyboard. This is called non-interactive mode, started with the `-p` option, and it is how most scripts, scheduled jobs and pipelines call it. When a program finishes, it hands back a small number called an exit code. By long convention, 0 means "it worked" and anything else means "it did not". Other tools, such as a build pipeline, read that number to decide whether to show a green tick or a red cross. Claude's documentation says Claude Code exits with code 0 on success and a non-zero code when the run fails, so scripts can act on the result. Two entries in the official changelog close gaps where that did not hold: - **Version 2.1.314, 30 October 2026.** The changelog says it fixed `claude -p` "exiting with code 0 and no output when startup failed". It now prints the error and exits 1. - **Version 2.1.317, 3 November 2026.** The changelog says it fixed `claude -p` "exiting 0 when a full disk or quota lost its transcript or ~/.claude.json writes". The transcript is the record of the session, and `~/.claude.json` is a settings and state file in the user's home folder. The run now prints an error and, in text and JSON output, exits 1. The same entry warns that full NFS exports (network-shared storage) may be missed, so a full network drive can still slip through. In plain terms: before these fixes, a run that never got going, or one that could not save its own working record because the machine was out of space, could still report success. Now it reports failure and says why. A third, related fix arrived on 4 November in version 2.1.318: `claude -p` and Agent SDK sessions (the toolkit for building programs on top of Claude Code) no longer report success when an API error cut off a reply while a particular kind of add-on was in use. That one is narrower, but it is the same kind of problem. ## Why does a false "success" matter? A false success is the most expensive kind of failure because nobody looks at it. A red cross gets attention. A green tick gets ignored. Imagine a nightly job that asks Claude Code to review the day's changes and write a summary for the product owner. If the job starts and stops with no output but reports success, the pipeline shows green. The product owner sees no summary and assumes there was nothing to report. A week later someone notices that nothing has been reviewed for days. The same applies to anything unattended: - A scheduled check for outdated packages that never actually ran. - A pull-request reviewer that stays silent, so changes look "reviewed" when they were not. - A report that is expected every Monday and simply does not arrive. None of these is a dramatic outage. They are slow gaps in a safety net you believed was there. ## What should a team do now? You do not need to rewrite anything. A short list is enough. 1. **Update Claude Code** on every machine and build runner that calls it automatically. The fixes are in 2.1.314 and 2.1.317, and the newest release in the changelog at the time of writing is 2.1.318 (4 November 2026). Ask whoever looks after your pipelines to confirm the version rather than assume it. 2. **Find your automated runs.** Make a short list of every place Claude Code runs without a person: scheduled jobs, pipeline steps, review bots. Many teams are surprised by how many they have. 3. **Look back at suspicious green ticks.** If a job once "passed" but produced no output, it may have been one of these cases. A quick look at the last few weeks of runs is cheap. 4. **Make failures reach a person.** A red pipeline that nobody reads is the same as a green one. Decide who gets told, and how, when an automated Claude Code step fails. 5. **Check the result, not just the signal.** Add one simple test of the outcome: the summary file exists and is not empty, the expected commit is there, the report was sent. An exit code says whether the program thought it succeeded; the outcome says whether you got what you asked for. ## Is there anything else in these releases worth knowing? Two small things, both from the official changelog. Version 2.1.317 also added a check that asks before a web or shell tool call sends your account email address to the network. It is a prompt before possibly sharing personal data, which is a sensible default for a tool that can run commands and reach the internet. Version 2.1.318 changed background subagents (helpers that Claude starts to work on a side task) so that a shell command moves to the background after 3 minutes on all providers. The stated reason is so the prompt cache does not expire while it runs. The prompt cache is a short-lived store of the conversation so far; if it expires, the long conversation has to be read in again from scratch. ## How does this fit with how Atlas works? Atlas is a team of AI engineers built on Claude Code. It has its own guard against a false "done". Completion is refused until the work is on the main version of the code or queued to land there, a screen has its test cases and screenshots, and the product's rules pass. That checks the result, which is the safer habit described above. What Atlas does not do today is read Claude Code's exit codes to catch a run that failed at startup, or explain each Claude Code update to you in plain words. Both are coming to Atlas, built in, so they will need no setup on your side. Until then, the route is the checklist above and the official [changelog](https://code.claude.com/docs/en/changelog). You can read more about the team on the [Atlas home page](https://bridge-terminal.com/atlas/). ## What is the short conclusion? A green tick is only useful if it means the work happened. These releases make Claude Code more honest when an automated run breaks, which is exactly when nobody is watching. Update, list your automated runs, send failures to a real person, and always check for the result you asked for. ## Questions people ask ### Did Claude Code ever report success when an automated run failed? According to the official changelog, yes, in at least two cases. Version 2.1.314 (30 October 2026) fixed a `claude -p` run exiting with code 0 and no output when startup failed. Version 2.1.317 (3 November 2026) fixed it exiting 0 when a full disk or quota lost its session record. ### What is an exit code in plain English? It is a small number a program hands back when it finishes. By convention 0 means it worked and anything else means it did not. Pipelines use it to show a green tick or a red cross. ### Which Claude Code version should I be on? The fixes are in 2.1.314 and 2.1.317. The newest changelog entry when this was written was 2.1.318, dated 4 November 2026, so updating to it includes both fixes. ### Do I still need to check the output of automated runs? Yes. An exit code only says whether the program believes it succeeded, and the changelog notes full network-shared drives may still be missed. A simple check that the expected file, commit or report exists tells you whether you got the result. ### Does Atlas read Claude Code's exit codes? Not today; that is coming to Atlas, built in, with no setup. What Atlas does now is refuse to mark work done until the change is on main or queued to land, screens have test cases and screenshots, and the product's rules pass. ## About Atlas: Atlas checks the result, not just the signal Atlas will not call work done until it is on main or queued to land, a screen has its test cases and screenshots, and the product's rules pass. Reading Claude Code's failure signals and explaining each update in plain words is coming to Atlas, built in, with no setup. — https://bridge-terminal.com/atlas/ ## Sources - [Claude Code changelog](https://code.claude.com/docs/en/changelog) - [Run Claude Code programmatically (headless / print mode)](https://code.claude.com/docs/en/headless) _Researched and drafted with Claude, then checked against the sources above. Atlas is an independent product, not affiliated with Anthropic or OpenAI._ ## Related - [Does an AI Coding Agent Share Your Code? Plain Guide](https://bridge-terminal.com/atlas/blog/does-ai-coding-agent-share-your-code-privacy/) - [How to Report a Bug to an AI Coding Agent](https://bridge-terminal.com/atlas/blog/how-to-report-a-bug-to-ai-coding-agent/) - [Claude Fast Mode Ends for Opus 4.8 on 30 November](https://bridge-terminal.com/atlas/blog/opus-fast-mode-removal-november-30/)