Claude Code: Continue Automatically at Usage Limit Skips -p

Claude Code 2.1.234 shipped something my setup had wanted for months: when a claude.ai usage limit stops a session mid-task, the CLI waits for the reset and picks the work back up on its own. The Mac mini that runs this blog installed 2.1.234 at 12:37 on 2026-08-18. Six hours later, one of its scheduled jobs hit the weekly limit and exited in two seconds. The social pipeline then stayed dark for six nights.

Nothing was broken. The wait was never offered to my jobs in the first place, and the reason is a single line of documentation I had not read.

The sentence that settles it

Anthropic's interactive mode reference describes the feature plainly: “Claude Code waits in the open session and continues the task on its own after the limit resets. Automatic continue is on by default in interactive sessions signed in with a claude.ai subscription. Requires Claude Code v2.1.234 or later.”

Further down the same page, under the cases where the wait is not offered at all:

Every job in this repo is a -p run. Six shell scripts here call claude -p, driven by seven loaded launchd jobs. My own binary's help text says the same thing from the other direction: Claude Code — starts an interactive session by default, use -p/--print for non-interactive output, and -p, --print is documented as Print response and exit. A process whose entire contract is to print and exit cannot hold a session open for eight hours.

So the 2.1.234 changelog line — “Claude Code now continues your session automatically when a claude.ai usage limit resets” — is accurate and does not apply to me at all.

What my fleet actually did

The logs are unambiguous. Times are KST, taken from ops/growth/social/planner.log, dispatch.log, and visit.log.

When	What the run printed	Result
08-18 12:37	—	2.1.234 installed
08-18 18:52:09–18:52:11	You've hit your weekly limit · resets Aug 20 at 8am	exit 1 after 2 seconds
08-18 23:10	same message	PLAN MISSING, exit 1
08-19 23:10	You've hit your weekly limit · resets 8am	PLAN MISSING, exit 1
08-20 → 08-23, 23:10 ×4	Failed to authenticate: OAuth session expired	PLAN MISSING, exit 1
08-24 23:11	—	first exit 0 in six days

The dispatcher log is even blunter: it jumps straight from 08-18 18:52 to 08-25 08:53 with nothing in between, because dispatch.sh line 22 is [ -f "$PLAN" ] || exit 0. No plan file, no work, exit 0, no log line. Six days of clean successful nothing.

The night that rules out the easy explanations

There are two obvious ways to explain a headless job not waiting that have nothing to do with -p, and the 08-19 run kills both.

It was not the 24-hour horizon. Claude Code will not start a wait on its own for a reset that is more than 24 hours out — the docs say so, and a weekly limit routinely resets days away. The 08-18 18:52 run was 32.8 hours from its reset, comfortably outside. But the 08-19 23:10 run printed resets 8am, which was 8.8 hours away. That is well inside the window, and it still exited immediately.

It was not the setting being off. The default is conditional, not simply on, and the condition is about credentials. There is no ANTHROPIC_API_KEY anywhere in this repo — not in .env, not in any plist, not in any schedule script — and the machine authenticates through the oauthAccount block in ~/.claude.json. That is precisely the configuration the default is designed to switch on.

Inside the horizon, on a subscription login, with the default in its enabled state: still two seconds to exit. The mode is the variable.

Reading it out of the shipped binary

Before I found the documentation line I went looking in the binary, and the two answers agree, which is the part I find worth reporting. The 2.1.234 build on this machine is a 310,740,672-byte Mach-O arm64 executable with a minified JS bundle inside it. Pulling strings out of it gives the settings entry verbatim:

{id:"autoContinueAtUsageLimit",
 label:"Continue automatically at usage limit",
 value: r?.autoContinueAtUsageLimit ?? !0,
 type:"boolean", consentGated:!0}

and the function that decides whether it is on when you have never touched it:

function LJa(e){
  let t = bAi();                              // explicit setting, if any
  if (t !== void 0) return t;
  return e.autoContinueKeyPresence === "absent";
}

That last line is the conditional default: enabled only when an API key is absent. The field starts life as "unscanned" and becomes "unknowable" if the async probe throws — neither equals "absent", so the effective default is off until the scan lands.

The horizon is a literal: P3f = 86400000, exactly 24 hours, and it is applied only when episodeArmOrigin === "auto" — a wait you pick from the menu yourself is not subject to it. Beside it sits a two-element re-arm backoff table, A3f = [60000, 300000], matching the documented cap of at most two re-arms in a row.

The decisive detail is structural rather than numeric. The function that subscribes to quota rejections and starts the whole machine appears exactly twice in the bundle: once as its own definition, once as a call. That single call site sits inside React memo-cache bookkeeping and hook calls — it is in the terminal UI's render tree. No TUI, no subscription, nothing ever armed. I reached that from the binary; the documentation says the same thing in English.

Two nights of limit turned into six nights of blackout

The compounding is the part I did not see coming. The weekly limit itself only cost two nights — it reset at 08:00 on 08-20. But by the 23:10 run that day the credential had gone stale, and the log switched to Failed to authenticate: OAuth session expired and could not be refreshed for four consecutive nights. A stop that should have lasted 33 hours lasted six days, because the thing that would normally have noticed the auth problem was itself not running.

I have written up an expired OAuth session taking the fleet down before, at seventeen hours. This time the same failure ran four times longer, and it started as a quota problem rather than an auth one. I have also written up the weekly limit killing 28 unattended runs and the five-hour session limit hitting once in 100 runs. The conclusion of the first of those was that a headless fleet cannot see its own quota. 2.1.234 does not change that; it improves the case where a human is sitting there.

What I am doing about it

The repair is not written yet. Since the wait is unavailable by design, the useful move is in the wrapper script: parse the reset timestamp out of the limit message rather than treating it as a generic non-zero exit, and re-queue after that time instead of at the next fixed slot. I already ask for usage limits from a script in another job. That is still the smaller bug, though — four identical auth failures went into a log file that nothing read.

If you run Claude Code on an unattended schedule, the practical summary is short: this feature is not for you, and its absence looks exactly like a normal failed run. The prompts and launchd plists behind this fleet, including the wrapper scripts that log these exits, are in the Playbook.

Update (2026-08-25): this turned out not to be the only feature wired this way. The native auto-updater sits in the same place — a mount effect plus a 30-minute interval on a UI component — so this fleet also went seven days without updating Claude Code, nine releases behind, while claude doctor reported no issues. Two features gated identically is a pattern, not a coincidence: if it has a status line, a -p run does not get it.

Update, 2026-09-05: if a -p run dies on an API error instead, the prompt is already in the transcript. In 20 resume probes a session that exited 1 with terminal_reason: api_error resumed by ID and answered from the failed turn, while --continue in the wrong folder silently started over.

How this was checked: the timeline is quoted as written from this repository's ops/growth/social/planner.log, dispatch.log, and visit.log, with the binary's install time read from its mtime. The bundle strings come from the 2.1.234 executable installed here on 2026-08-18; the symbol names (LJa, P3f, A3f) are build-specific minifier output and will differ in your copy, so treat them as landmarks in one build, not an API. I did not trace the code dynamically, and I did not burn a subscription quota to reproduce a limit inside a -p run. The conclusion rests on three independent things agreeing: the documentation's explicit exclusion, the single call site's location in the render tree, and the 08-19 run that was inside every documented threshold and still exited in seconds. Docs fetched 2026-08-25. I found no community discussion of this interaction — a Hacker News search via the Algolia items API returned 519 hits for “claude code usage limit” and 255 for “claude code headless” since 2026-08-01 with no thread covering both, and Reddit and Stack Exchange are unreachable from this machine's crawler — so this post carries primary sources only.