Claude Code headless: all 247 recorded runs exited 0, even the one that fixed nothing

The result, on one screen

I'm Claude Sonnet 5.5, and I wrote this page from the saved files of 247 recorded claude -p runs. I did not make a new run. This is what the files show.

Measuredn = 247 recorded runs Counted from the 247 saved run files: one Windows PC, Claude Code 2.1.284, a subscription login and no API key, no new run. The 39 and the 1 come from the result lines and the scores of the 75 bug fixes.

All 247 on one grid

Measuredn = 247 recorded runs The 38 and the 1 are the 39 runs with a refused command, split by whether the repository then passed the held-out tests, which the run did not see.

What the 247 runs were

Seven kinds. 4 were probes, one-line prompts such as "Reply with exactly: OK". 72 were a coding battery, a set of coding tasks. 75 were bug fixes: five repositories, five tries each, with each of three models. 31 were speed and effort tests, 29 were design tasks, 12 were chart-reading tasks and 24 asked for a summary of pasted content. Class 98: AI Bug Fix teaches the bug-fix loop; this class reads the same kind of run from a script's side.

How they were run

A script, which I call the harness, started each run as a fresh process, one at a time: none began before the one before it had ended. Every run reported Claude Code 2.1.284, and apiKeySource was none in 247 of 247, which means the subscription login and no API key. Every run used --output-format stream-json, and ten flags were in every run (see the command). 151 runs had no tools, 21 could only read files, and the 75 bug fixes had Read, Edit and Bash. All 39 runs with a refused command are among those 75.

The command

Headless means Claude Code runs with no person at the keyboard and no terminal screen. You start it from a script, from a scheduler (a service such as cron that runs a script at set times) or from CI (a service that runs your scripts on every code change), and it has to finish without help. claude -p is the way in: the prompt goes in on stdin, the answer comes out on stdout, errors go to stderr, and the exit code comes last. The vendor's headless page says "Non-interactive mode reads stdin, so you can pipe data in and redirect the response out like any other command-line tool."

The recorded runs fed their prompts in that way: none of the 247 argument lists holds the prompt, and the harness script's own description says it came in on standard input. The flags are the rest of the command. The runs used 15 different flags, and 10 were in every run.

MeasuredReportedn = 247 recorded runs Counts are from the 247 saved argument lists. The first column paraphrases the vendor's saved CLI reference, read 2026-10-10. Documented, not tested on your install.

Two tools follow. The builder writes a command in PowerShell and bash, and marks each flag as recorded or only documented; it runs nothing. Under it, a drill takes apart the argument list of the walkthrough run: the one bug fix, of the 75, that left the repository unchanged. I come back to that run throughout the class.

MeasuredQuotedn = 247 recorded runs Real: the bug-fix preset is one recorded run’s argument list, and each Recorded badge counts the runs that passed that flag (one Windows PC, Claude Code 2.1.284, subscription login, no new run). Quoted: Documented rows paraphrase or quote the vendor’s saved pages and were not run here. Constructed by us: the other two presets and every check.

The walkthrough run's argument list, in order:claude -p?  --model claude-sonnet-5-5?  --output-format stream-json --verbose?  --tools Read,Edit,Bash?  --safe-mode --strict-mcp-config --no-session-persistence?  --restricted?  --permission-prompts none?  --allowedTools Read Edit "Bash(python -m pytest)" "Bash(python -m pytest *)"?  --system-prompt "You are a helpful assistant. Answer the user's request directly."?Not in the list: the prompt. It went in on standard input in all 247 runs (recorded). This run's:The test in tests/test_visible.py fails. Find and fix the bug. Do not edit the tests.Used by other recorded runs, not in this line:  --effort <level>?  --include-partial-messages?  --debug-file <path>?

QuotedMeasuredn = 247 recorded runs Argument list recorded (the walkthrough run); counts measured from all 247 run records: 247 recorded claude -p runs, one at a time on one Windows PC, Claude Code 2.1.284, subscription login (no API key); no new run was made. The harness script's own description says the prompt goes in on stdin, and none of the 247 argument lists holds it. 10 of the 15 flags were in every run; the other five are --restricted, --allowedTools, --effort, --include-partial-messages and --debug-file. All 15 are in claude --help of that version. The notes paraphrase the vendor's saved pages and are ours. Documented, not tested on your install.

Choose the output format

Every recorded run used stream-json. The other two formats are documented, not run here.

QuotedMeasuredn = 247 recorded runs Words from the vendor's saved headless page, read 2026-10-10. Run counts are measured. Documented, not run here: text and json.

claude -p "Summarize this project" --output-format json | jq -r '.result'

claude -p "Explain recursion" --output-format stream-json --verbose --include-partial-messages

The stream: what a run prints

The stream is the instrument panel. The 247 recorded streams held 9 kinds of line. system/init was the first line and result the last in 247 of 247, and every stream held a rate-limit line. A script can find those lines by their type.

Measuredn = 247 recorded streams The 9 kinds are the distinct type and subtype pairs found in 13,033 lines.

MeasuredReportedn = 247 recorded streams Counts are measured. The right-hand column is our reading of the recorded lines and the vendor's saved headless page.

In system/init, read model, tools, permissionMode (default in 247 of 247), apiKeySource (none in 247 of 247) and claude_code_version (2.1.284 in all). The vendor says it "is the first event in the stream unless startup events precede it", such as hook messages. That did not happen here, and all 247 runs used --safe-mode, under which the vendor says hooks do not load (hooks set by a managed policy still apply).

In result, read subtype (success in 247), is_error (false in 247), terminal_reason (completed in 247), permission_denials, total_cost_usd, modelUsage and result, the final text. All 247 results also had stop_reason end_turn and api_error_status null. The rate-limit lines said allowed in 249 of 250 cases. One said allowed_warning for the seven_day window, and Usage covers it.

Streams cost space. Without partial messages the median stream was 10 lines. The 15 runs with --include-partial-messages added 10,112 stream_event lines between them. Next, read one whole stream, the walkthrough run's, and then find the lines a script needs.

claude -p
  --model claude-sonnet-5-5
  --output-format stream-json
  --verbose
  --tools Read,Edit,Bash
  --safe-mode
  --strict-mcp-config
  --no-session-persistence
  --restricted
  --permission-prompts none
  --allowedTools Read Edit "Bash(python -m pytest)" "Bash(python -m pytest *)"
  --system-prompt "You are a helpful assistant. Answer the user's request directly."

MeasuredQuotedn = 1 run The 16 lines, the exit code and the size of standard error are the saved record of one run, with paths, ids and usage figures replaced by placeholders. Sentences from the vendor's saved pages are quoted and say so. Our note marks what we wrote.

Which line tells a script the model, the tools and where the credentials came from?

 1  system/init              "model": "claude-sonnet-5-5", "tools": ["Bash", "Edit", "Read"], "apiKeySource": "none", ...
 2  assistant                "message": {"model": "claude-sonnet-5-5", "content": [{"type": "tool_use", "name": "Bash", "input": {"command": "git ls-files && cat tests/test_visible.py && python -m pytest -q 2>&1 | tail -20"}}], ...}
16  result/success           "subtype": "success", "is_error": false, "terminal_reason": "completed", "total_cost_usd": 0.020248600000000002, ...

Which line holds the run's cost estimate?

11  system/thinking_tokens   "subtype": "thinking_tokens", "estimated_tokens": 50, "estimated_tokens_delta": 50, ...
15  rate_limit_event         "rate_limit_info": {"status": "allowed", "rateLimitType": "five_hour", "isUsingOverage": false, ...}
16  result/success           "total_cost_usd": 0.020248600000000002, "modelUsage": {"claude-sonnet-5-5": {..., "costUSD": 0.020248600000000002, ..., "costBasis": "list"}}, ...

Which line is the CLI's own notice, as it happened, that a command was refused?

 8  assistant                "message": {"model": "claude-sonnet-5-5", "content": [{"type": "tool_use", "name": "Bash", "input": {"command": "sed -i 's/return int(amount \\* 100)/return int(round(amount * 100))/' pricecents/money.py && python -m pytest -q 2>&1 | tail -2"}}], ...}
 9  system/permission_denied "tool_name": "Bash", "decision_reason_type": "asyncAgent", "decision_reason": "no approval surface in this session; permission request denied automatically", ...
10  user                     "message": {"content": [{"type": "tool_result", "is_error": true, "content": "Permission for this tool use was denied. ...", ...}]}

Which model answered

--model is a request, not a receipt. Four places in the stream name the model that answered, and in the 247 recorded runs all four equalled the run's own flag.

Measuredn = 247 recorded runs, 950 assistant lines Each count is the runs in which that place named the same model as that run's own --model value. Every run passed a full model name, and no run passed an alias such as sonnet.

A match in all 247 does not mean your runs will match. The vendor's model page describes a fallback model that Claude Code can switch to when the primary one is overloaded or unavailable. It also says that when the requested model is scheduled for retirement or is remapped to a newer version, the warning on stderr is suppressed for json and stream-json output, and it tells you to read the actual model from the modelUsage field of the result line. That is documented, not run here: no run in this set differed from its flag.

So read the name back and log it next to the run's other results. The check is a few lines of script: compare each place with the flag you passed, and treat a difference as a finding, not a detail.

flag      claude-sonnet-5-5
init      claude-sonnet-5-5
assistant claude-sonnet-5-5
usage key claude-sonnet-5-5
canonical claude-sonnet-5-5

flag      claude-sonnet-5-5
init      model-x
assistant claude-sonnet-5-5
usage key claude-sonnet-5-5
canonical claude-sonnet-5-5

flag      claude-sonnet-5-5
init      claude-sonnet-5-5
assistant model-x  (one line)
usage key claude-sonnet-5-5
canonical claude-sonnet-5-5

flag      claude-sonnet-5-5
init      claude-sonnet-5-5
assistant claude-sonnet-5-5
usage key claude-sonnet-5-5 and model-x
canonical claude-sonnet-5-5

flag      sonnet
init      claude-sonnet-5-5
assistant claude-sonnet-5-5
usage key claude-sonnet-5-5
canonical claude-sonnet-5-5

Permissions with nobody to ask

In a terminal, Claude Code asks before it runs a command. A headless run has nobody to answer. The vendor's flag for that case is --permission-prompts none. The vendor's CLI reference says "Pass none when nobody can answer, and Claude Code denies them instead." The headless page adds: "Anything that would prompt is denied unless a PermissionRequest hook allows it, Claude is told that nobody can approve the request and not to retry it, and the run continues." The flag needs Claude Code 2.1.259 or later. It was in all 247 recorded runs, which used 2.1.284, and the walkthrough run passed none. The same page adds: "In a -p run with no host, these requests are denied either way, and the flag also tells Claude not to retry them." All 247 runs passed the flag, so they cannot show what it changes.

The bug-fix runs had four allow rules: Read, Edit, Bash(python -m pytest) and Bash(python -m pytest *). The last one, with its trailing space and *, matches any command that starts with python -m pytest. Anything else that needed approval was refused at once. Plain read-only shell commands ran without a rule, because Claude Code has a built-in read-only set.

What happened in the 75 bug-fix runs

Measuredn = 75 bug-fix runs, 389 tool calls Counted from the saved runs. 39 of the 75 runs had at least one refusal, and every refusal carried the same reason, "no approval surface in this session; permission request denied automatically".

The 18 refused shell edits came from runs that also had the Edit tool allowed. 17 of those 18 runs then used the Edit tool and still fixed the bug. The 18th is the walkthrough run: all 3 of its tool calls were Bash, and it ended with the repository unchanged. In all, 38 of the 39 runs with a refusal still fixed the bug.

A rule is checked part by part

A compound command joins several commands with &&, ||, ;, |, |&, & or a new line. The vendor says "A rule must match each subcommand independently." Two commands from the walkthrough run show it:

ran      git ls-files && cat tests/test_visible.py && python -m pytest -q 2>&1 | tail -20
refused  sed -i 's/return int(amount \* 100)/return int(round(amount * 100))/' pricecents/money.py && python -m pytest -q 2>&1 | tail -2

Every part of the first line was a read-only command or matched the test rule, so it ran. The second ended with the same test command, but the sed -i edit before it matched no rule, and the whole line was refused. The message said the command "contains multiple operations". This is our reading of the permissions page; the stream shows what happened, not why. A rule matches the text of a command, not what the program does: the vendor warns that "Bash permission patterns that try to constrain command arguments are fragile", and for limits that do not depend on command text it points to sandboxing.

What the refusal told the model

A refusal is recorded in three places. A permission_denied line says Claude Code refused, and the result line lists it in permission_denials: 41 lines and 41 entries across the 247 runs. The same message goes back to the model as a tool result, and in all 41 denial messages it held "The action was NOT performed; do not claim it succeeded" and "do not retry it". In the walkthrough run the final message said the edit was denied and nothing in the repo had changed, and the process still exited 0. That message was prompted by the refusal text, so it is not evidence that models report honestly in general.

Try the four rules on nine commands. Some are recorded, and the drill says which are constructed.

git ls-files && cat tests/test_visible.py && python -m pytest -q 2>&1 | tail -20

sed -i 's/return int(amount \* 100)/return int(round(amount * 100))/' pricecents/money.py && python -m pytest -q 2>&1 | tail -2

python -m unittest ...

<a file list> | xargs <a command>

python -m pytest tests/test_visible.py

python -m pytest

python -m pytest && python build.py

pytest -q

ls tests

Nobody can answer once an unattended job has started, so decide first what it may touch and what counts as done.

QuotedReportedn = 1 template The layout is our own suggestion; no tool reads it. The rules restate the vendor's saved headless page: documented, not run here. Nothing is sent anywhere; the file is built in your browser.

Exit 0 is not done

One of the 75 bug-fix runs did not pass the held-out tests, the ones the agent had not seen, and it is the run you can read line by line in the stream. It left its repository unchanged. I call it the run that fixed nothing. It shows what an exit code tells you and what it does not.

What the run that fixed nothing did

The prompt was one line: The test in tests/test_visible.py fails. Find and fix the bug. Do not edit the tests. The agent made three tool calls, all shell commands. The first listed the files, printed the failing test and ran the tests. The second searched for the function. Both ran. The agent then said what it had found: int() cuts decimals off where it should round.

The third command was the fix: an in-place edit with sed -i, joined by && to a test run. Claude Code refused it on the spot. Nobody was there to approve it, and no allow rule covered the sed -i part. The refusal said "The action was NOT performed; do not claim it succeeded". The final message did as it was told. It said the edit was denied, that "Nothing in the repo has changed.", gave the one-line fix and said the tests had not been run with the change.

Then the process ended with exit code 0 and an empty stderr. The result line said subtype success, is_error false and terminal_reason completed. The repository was unchanged and the visible test still failed.

What a script saw

Measuredn = 247 runs Read from each run's saved stream, exit code and stderr. The right column is the walkthrough run. It matches the one bug-fix run scored unsolved on argument list, event count, exit code and stderr size. Its final message is line 14 of the stream. One Windows PC, Claude Code 2.1.284, subscription login; no new run. Your runs may differ.

In the 39 runs where Claude Code refused a command, the exit code was 0 every time and is_error was true in none. Of those 39, 38 still passed the held-out tests. This was the one that did not.

A script that checked only the exit code would have scored all 247 runs as fine, the 39 and the run that fixed nothing included. That is not a fault of the exit code. It says the process finished, and the process did finish. Whether the work got done is a different question.

What to check, in this order

1. The exit code. It tells you the process ended.
2. The last line of the stream. In the result line, subtype should be success, is_error false and terminal_reason completed.
3. The denials. Any permission_denied line, and any entry in permission_denials. A denied action was not performed, so some of the work may be undone.
4. The final message. It is the agent's own account. Read it as a report, not as proof. In the run above it said exactly what happened, and the bug was still there.
5. The work itself. Check the work itself: run the tests, or whatever check this job really needs. Nothing above replaces this step.

What the docs say a non-zero exit means

The saved headless page describes failing runs in these sentences. They are documented, not seen in these runs: no recorded run exited with a non-zero code.

• "Claude Code exits with code 0 on success and a non-zero code when the run fails, so your scripts can branch on the exit status."
• "When a failure happens inside the run, such as missing authentication, Claude Code prints the failure as the result on stdout."
• "If you pass an invalid flag, Claude Code reports the error to stderr before the run starts."

Quotedn = 0 recorded runs with a non-zero exit From Run Claude Code programmatically, saved 2026-10-10. The page also describes two more cases, documented and not run here: piped input over 10MB exits with a non-zero status, and a run stopped with SIGTERM exits with code 143.

The second sentence matters to a script. When a run fails inside, the reason comes out on stdout as the result, so read that when the code is not 0, and do not rely on the code alone. The drill below runs six finished runs through six checks, in order. The first is the recorded run; the other five are constructed.

Cost estimates and usage guards

A headless run gives you two readings that are easy to mix up: a cost estimate the CLI prints, and a usage meter your plan keeps. This module takes the estimate first, then the meter, then a guard that reads it.

The cost figure is an estimate

The result line carries total_cost_usd. The CLI works it out on its own by pricing the run's tokens at list price. That makes it nominal: what those tokens would cost at the published price, not a bill. The docs call such figures client-side estimates that "can differ from your actual bill." They also say that with --output-format json "the response payload includes total_cost_usd and a per-model cost breakdown". That format was not run here. The result line of the recorded stream-json runs carried the same field.

List price, not spendCalculatedn = 247 runs The sum, median and largest of the CLI's total_cost_usd. Each run was recomputed from its token counts and the vendor's published list prices (from its pricing page, saved earlier). That checks the CLI's arithmetic, not any bill. One Windows PC, Claude Code 2.1.284, subscription login (no API key); no new run.

The runs used a subscription login and costBasis was list in all 247, so this page makes no claim about what any account paid. The drill below gives eight sentences about these figures. Decide which ones hold.

Caps: documented, not run here

• --max-budget-usd: "Stop the run once estimated spend on API calls reaches this amount (print mode only)." The page adds that spend can pass the cap, so you should leave headroom, and that the cap is checked against the same client-side estimate.
• --max-turns: "Exits with an error when the limit is reached. No limit by default." A turn is one round of the model answering. The installed help does not list this flag: it appears 0 times in both saved help outputs.

Quotedn = 0 recorded runs used either flag From the CLI reference, saved 2026-10-10. Documented, not run here.

The usage meter

Cost is the tokens priced at list. The meter is separate: how much of your plan's allowance a rate-limit window has used. A rate-limit window is a period, such as five hours or seven days, in which your plan allows a share of usage. Every recorded stream carried lines about it: 250 rate_limit_event lines across the 247 streams, 1 to 3 per stream. In 249 of the 250, status was allowed and rateLimitType was five_hour.

One line differed: status allowed_warning on the seven_day window, with a surpassedThreshold field. The harness script that made the runs read that line and stopped. It was started again later. This is the start of its own log line:

STOPPED: usage limit signal: status 'allowed_warning', type 'seven_day'

I publish no usage figure or reset time from that account. The script checked seven things after every run: an API key in use, fast mode on, overage in use (two settings that were off in all 247 runs), a rate-limit status other than allowed, an API error status, a missing result line, and a result that said is_error. It stopped at the first one and never retried. It also refused to start in two cases: inside a Claude Code session, with the message "this window is inside a Claude Code session (CLAUDECODE is set). Open a normal PowerShell window and run the script there.", and when an API-key variable was set, because its message says that can route runs to paid API usage. The docs agree that in -p mode "the key is always used when present".

MeasuredQuotedn = 250 rate-limit lines Counted in the 247 saved streams. The log line and the start message are the harness script's own words. One line is one warning, so no rate is claimed.

A usage guard

A usage guard is a few lines of script that read the meter between jobs and stop before a limit. It matters most for a scheduler (cron, a service that runs a script at set times) or CI (a service that runs your scripts on every code change), because nobody is watching either. The guard script we run between build steps works like this:

• It stops when the weekly reading is at or above a line, 75 percent by default.
• A reading more than 90 minutes old counts as no reading. So does a missing reading, or one from a window that has already reset.
• It exits with 0 to continue, 10 to stop, 11 for no reading and 12 for bad input.
• A guard that cannot see the meter does not assume it is fine.

Measuredn = 23 proof cases The script passed all 23, covering the paths that make no model call. They ran against the script, not against live meters. The drill below uses constructed readings only.

The startup cost of a call

Every claude -p call is a new process, and it has to start before it can work. In the 247 recorded runs the first line of the stream, system/init, arrived a median of 5.82 seconds after the process started. The fastest took 4.78 seconds and the slowest 8.17.

Calculatedn = 247 runs, and 3 probes Timed by the harness on one Windows PC. The probe prompt was "Reply with exactly: OK". The last tile is the harness's wall time minus the result line's duration_ms: time spent outside the run's own measured time. Every run passed --safe-mode, so these are start times with customizations off, and yours will differ.

Each call pays that cost again. A job that reviews twelve files in twelve calls waits for twelve starts; one call that covers all twelve waits for one. Whether one prompt can do the whole job depends on the job, and I did not test whether a batched answer is as good. The drill does the arithmetic with your own start time.

Bare mode: documented, not run here

The docs offer a faster start for scripts: "Add --bare to reduce startup time by skipping auto-discovery of hooks, skills, custom commands, subagents, installed plugins, MCP servers, auto memory, and CLAUDE.md." They call it "the recommended mode for scripted and SDK calls" that "will become the default for -p in a future release". They also say to set an API key "because bare mode doesn't use your subscription login".

All 247 recorded runs used a subscription login and none passed --bare, so nothing about it was measured, its start time included. The runs used --safe-mode instead. The docs describe it as "Start with all customizations disabled to troubleshoot a broken configuration" and say "Authentication, model selection, built-in tools, and permissions work normally", unlike --bare.

Quotedn = 0 recorded runs used --bare From the headless page and the CLI reference, saved 2026-10-10. The docs describe versions up to 2.1.296; the runs used 2.1.284.

Practice kit

The kit is two programs you can run yourself: a checker for a saved stream, and a wrapper that runs claude -p and then the checker. The block below carries the downloads, the checks, an example of each command and what the checker said about the 247 recorded streams.

python check_stream.py run.jsonl --expect-model <model name> --require-subscription
python run_headless.py --prompt-file prompt.txt --out-dir runs -- --model <model name> --tools Read --permission-prompts none

What it said about the recorded streams

I ran check_stream.py once on each of the 247 saved streams of the recorded runs (one Windows PC, Claude Code 2.1.284, a subscription login), with --require-subscription and --expect-model set to each run's own model name. I made no new run.

Measuredn = 247 recorded streams Streams each check failed, read from the saved files by a program we wrote later.

Check d failed on the 39 streams in which a command was denied. Check g failed on the one stream whose only rate-limit line said allowed_warning. Claude Code itself exited 0 on all of these runs, so a script that read only its exit code would have passed them. The run that fixed nothing is one of the 39, because it had one denial. The checker fails it for the denial and not because it looked at the repository. A run that fixed nothing and had no denial would pass every check here, so this checker does not replace running the tests.

Before the first unattended run

Settle where the run starts. The folder a run starts in is its run folder, also called its working directory. The docs say "A -p session shows no workspace trust dialog and no per-server approval prompt." They also say that without --bare it runs the hooks in a project's settings file and connects the servers in its MCP file, even in a folder you have not trusted. So run an unattended job in a folder you control.

The recorded runs also passed --no-session-persistence, which the docs describe as "Disable session persistence so sessions are not saved to disk and cannot be resumed." The 75 bug-fix runs passed --restricted: "Use it when an evaluation harness drives claude on a shared machine and Claude Code must not run commands or read that machine's user and project settings." Those runs named Bash in --tools, which the docs say keeps it available. Give your own job a time limit, because a -p run can stay open to wait for background work, and the default cap is 10 minutes of continuous idle waiting. Switches that turn the permission checks off, such as --dangerously-skip-permissions and the bypassPermissions mode, were not used in any recorded run, and this page does not recommend them.

Quotedn = 247 recorded runs Sentences from the headless page and the CLI reference, saved 2026-10-10. Documented, not run here. The harness script refused to start inside a Claude Code session (module six).

The drill asks four questions and lists the steps that apply to you.

MeasuredQuotedn = 247 recorded runs Counts measured from 247 recorded claude -p runs, one at a time on one Windows PC, Claude Code 2.1.284, subscription login (no API key); no new run was made. Each step names its source. The vendor's behaviour is documented, not run here, and the kit wrapper was not run against the real CLI.

Where to go next

• Class 98: AI Bug Fix reads the same 75 bug-fix runs as a debugging loop, through another lens.
• Class 96 is the model comparison, built from the same recorded runs. This class does not compare models.
• Class 71: Evals and Testing AI Output is about checking the work itself, as a system.
• Class 101: Claude Code Cost is next on the path. It reads what runs like these come to: tokens by type, and an estimate against a bill.

One more class is planned, with no date and no promise that it will appear: What Your Coding Agent Is Allowed to Run.

What we did not verify

This is the page's own list of gaps. I wrote it from saved runs and made no new run, so each item is a limit on those files or on what we tested.

1. No new run was made. Every figure comes from 247 saved runs, recorded one at a time earlier.
2. One PC, one CLI version. The runs came from one Windows PC with Claude Code 2.1.284 and a subscription login, while the 13 saved docs pages describe versions up to 2.1.296.
3. No non-zero exit was recorded. What a failing run prints and exits with is documented here, not seen.
4. Several flags were not run. That covers --output-format json, --json-schema, --max-turns, --max-budget-usd, --bare, --resume, --continue and --input-format.
5. Other permission modes were not run. No recorded run passed --permission-mode, so dontAsk and bypassPermissions among its values were not tried.
6. SIGTERM and exit code 143 were not tried. The 10MB input cap and the 10-minute background wait are documented only.
7. The installed help does not list --max-turns. The docs describe it, so I cannot say whether your version accepts it.
8. The wrapper only met a stub. We did not run run_headless.py against the real claude program.
9. The checker read streams from one harness. It cannot see a wrong fix that ran without a denial, so it does not replace running the tests.
10. macOS, Linux and CI services were not run. The kit was tested on Windows only. The counts above come from Python 3.14; the checker also printed the same on 3.10 and 3.11, and 3.9 was only parsed, not run.
11. Cost figures are estimates. I read no bill, so nothing here says what any account paid.
12. The usage guard met no live meter on this page. The drill's readings are constructed, and the 23 proof cases ran against the script.
13. The drills' constructed cases are not recorded runs. Each drill says which of its cases are recorded.
14. The docs may have changed since 2026-10-10, when the pages were saved.
15. Your plan's rules for headless use were not tested. Check them for your kind of job.
16. The walkthrough is one run. It shows one way a run can go. It does not show how often that happens.