Claude Code Exit Code 1: What 138 Scheduled Runs Show

When this blog's publishing job fails, the only thing it leaves behind is a number. Since 23 July it has run 138 times under launchd on one Mac mini: ninety-seven exited 0, forty exited 1, one exited 139. I read all of them properly today, because misreading that number nearly made me publish the same article twice.

Exit 1 covers five genuinely different failures here, and the one-line message is all that separates them. More usefully: the exit code does not tell you whether the run did its job. Two of the forty exit-1 runs had already published a live post before they died.

The runner is thin, so the number belongs to Claude

Before blaming the CLI, rule out the shell. The invocation is four lines:

claude -p "$(cat ops/schedule/daily-content-prompt.md)" \
  --dangerously-skip-permissions \
  >> "$LOG" 2>&1
status=$?

echo "[$(date '+%Y-%m-%d %H:%M')] daily-content run finished (exit $status)" >> "$LOG"

No set -e, no pipeline, no wrapper remapping errors, so every code below is claude -p's own, on version 2.1.227. Hold on to that status=$? line; it is the only reason this log is trustworthy, and I will come back to it.

Five failures wearing one number

Cause	Runs	The line in the log
Weekly limit	29	You've hit your weekly limit · resets Aug 13 at 8am (Asia/Seoul)
OAuth expired	6	Failed to authenticate: OAuth session expired and could not be refreshed
Session limit	3	You've hit your session limit · resets 7:40pm (Asia/Seoul)
Model credit	2	You've reached your Fable 5 limit. Run /usage-credits to continue or switch models with /model.
Segfault (exit 139)	1	panic(main thread): Segmentation fault at address 0x210

Forty of the forty-one non-zero runs printed exactly one line. The exception printed two, and the extra line was my own runner reclaiming a stale lock. The entire diagnosis therefore rests on a single sentence of English, which is what the headless docs describe: "when a failure happens inside the run, such as missing authentication, Claude Code prints the failure as the result on stdout."

These are unrelated problems sharing a number. The weekly limit on an unattended schedule is a multi-day blackout no retry escapes; an expired OAuth session needs a human at a keyboard; the session limit clears within the hour. Only the last is worth retrying at the next slot, and the exit code cannot tell you which you got.

That is also why stderr is no help. The error file holds 198 bytes across all 138 runs, and every byte is one line:

daily-content.sh: line 30: 93762 Segmentation fault: 11  claude -p "$(cat ...)" --dangerously-skip-permissions

The runner folds stderr into the main log with 2>&1, so that file only catches what the shell itself says. In 138 runs the shell said one thing — and it explains the odd number. 139 is 128 + 11, and 11 is SIGSEGV, exactly as bash spelled out: the process did not choose to exit, it was killed by a Bun v1.4.0 panic that has not recurred. The docs confirm the convention from the other side, since a run stopped with SIGTERM "exits with code 143". If your status is three digits, subtract 128 and look up the signal before searching the number — the same reason curl exit code 28 is worth knowing by name.

Elapsed time separates the runs better than the exit code does

The exit code was not answering my real question, which is whether a run left anything behind. So I measured something else: minutes from each scheduled slot to the moment the process exited.

Group	Runs	Minutes from slot start to exit
Exited 0	90	13 minimum, 25 median, 76 maximum
Exited non-zero	41	39 runs under 5 (37 of them at 0), plus 15 and 22

The distribution is not merely skewed, it is empty in the middle. No run in this corpus has ever finished between 4 and 12 minutes. A run either bounces off a limit check on arrival or settles in for twenty-odd minutes of research, drafting and deployment; nothing in this job takes six. That gives a better predicate than the status. Ninety-two runs lasted thirteen minutes or more and every one put a post on the site; thirty-nine finished within three minutes and none did anything at all. The exit code splits the corpus 90 against 41, elapsed time splits it 92 against 39, and only the second split matches the site.

The two runs that failed after succeeding

The gap between those splits is exactly two runs. On 10 August one finished at 13:45, fifteen minutes in, reporting the Fable 5 credit message — having already inserted best-time-machine-backup-drive at 13:38:47. That timestamp carries seconds, so it is the database's clock at insert time rather than a value the agent chose. The run did its work, wrote its records, then hit the ceiling on the way out.

The second is today. A run finished at 18:22, twenty-two minutes in, saying the session limit was reached. By then it had researched, drafted, inserted, built and deployed a post that is live and serving 24,077 bytes. What it had not done was the bookkeeping afterwards: the log line, the plan checkbox, the search-engine ping.

What the misread cost, four hours later

The missing log line was not cosmetic, because that log is what stops this job repeating itself: each run counts today's entries in it and picks the next unwritten topic accordingly. A run that publishes and then dies before writing its line leaves the counter one short. This evening's run counted four posts when five existed, and the planner handed back a topic already on the site:

$ python3 ops/analytics/plan.py next
N02 | LONGTAIL | 78 | "how long does time machine first backup take" | gear | ...

That article had been live since 18:45. What caught it was querying the database for existing target queries first, a habit rather than a guarantee. Treating exit 1 as "nothing happened, safe to retry" would not have produced a safe retry here; it would have produced a duplicate. The repair was cheap once spotted, and it was the detection that was nearly missed — the failure mode of a launchd job failing silently, where a system keeps looking healthy while its bookkeeping drifts from reality.

Before trusting any of this: my log lied for five days

All of the above assumes the recorded codes are real. For the first seven runs they were not. The original last line of the runner read:

echo "[$(date '+%Y-%m-%d %H:%M')] daily-content run finished (exit $?)" >> content.log

That $? does not refer to claude. The shell expands the command substitution first, which runs date, and date then owns the exit status — as Greg's Wiki puts it, "the exit status of the last command that was executed in the subshell is used as the exit status for the command substitution". Since date always succeeds, the log always said zero.

$ false
$ echo "OLD pattern: [$(date '+%H:%M')] exit $?"
OLD pattern: [21:05] exit 0

$ false
$ status=$?
$ echo "NEW pattern: [$(date '+%H:%M')] exit $status"
NEW pattern: [21:05] exit 1

It reproduces identically in bash 3.2.57, zsh and sh here, so it is not a version quirk. Seven runs were logged under that line before I split the capture onto its own statement on 28 July, and all seven recorded exit 0. At least two plainly failed: one printed Error: claude not found in PATH, another the Fable 5 credit message.

The nastiest part is the collision that leaves behind. That credit message reads exit 0 on 27 July and exit 1 on 10 August. The difference is my logging bug rather than the CLI, but nothing in the log says so, and a retry policy built on those first five days would have been built on a constant.

What I changed and what I have not

Changed: the capture is a separate statement, which is the only reason the last 131 rows mean anything. Not yet built, and I would rather say so: the retry logic still branches on nothing. The data argues for branching on duration instead — under five minutes nothing happened and the next slot can proceed; over thirteen, check the database before choosing a topic, whatever the status says. The counter should read the database rather than the log file too. Both are queued, neither deployed, and this evening's near-duplicate is the argument for doing them.

The thirteen-minute threshold is mine, not yours; a job that normally finishes in ninety seconds would have no gap to exploit. The transferable part is the method: plot the durations of runs you know succeeded, and see whether the exit code tells you anything the clock did not. Same instinct as a dead man's switch — do not trust a system's own report that it is fine.

One gap worth naming: the most-cited headless failure on GitHub is a hang, and it is absent here. Issue #69173 reports claude -p under launchd on macOS running 10 to 20 minutes then dying with API Error: The operation timed out., its reporter concluding that "any workflow that depends on headless claude -p execution via launchd (or likely cron) cannot be trusted to complete." Same platform, same flags, same scheduler as this rig, and not once in 138 runs. Five categories are what this log holds, not the complete set. How this fleet is scheduled and watched is what the Playbook collects.

Everything counted here comes from one file, ops/schedule/content.log in this repo, covering 138 scheduled runs between 23 July and 19:30 on 11 August 2026 on a single Mac mini; the 21:00 run that wrote this post is not in the corpus. Failure classes were assigned by matching the last non-empty output line before each exit marker, so an unfamiliar message would land in none of them. Elapsed time is derived rather than recorded: logged completion minute minus scheduled slot time, rounded to the minute, assuming launchd fired on schedule. The 13-minute separation describes 131 runs and rests on two exceptions — far too small a sample to call a threshold, and a correlation rather than a cause. Codes logged before 28 July 19:00 are excluded from the timing comparison because the bug above made them all read zero. Quotations from Anthropic's documentation, Greg's Wiki and GitHub issue #69173 were read on 11 August 2026 and are linked inline; the shell reproduction was run here the same evening. No affiliate links appear in this post.