Anthropic's documentation describes the non-interactive mode as the same tools, agent loop and context management as Claude Code, available as a command for scripts and CI/CD. You pass -p with a prompt; it exits with 0 on success and a non-zero code when the run fails (Source 1). Nobody is there to answer a permission prompt, so everything a person would normally approve has to be decided in advance: which tools are allowed, which mode applies, how much it may spend.

One thing to know before automating: without the --bare flag, a -p run behaves like an interactive session. It runs the hooks in a project's .claude/settings.json and connects the servers in its .mcp.json, even in a folder you have never trusted, with no trust dialog and no approval prompt (Source 1). Chapters 22 and 23 saw the first half of that in practice: the project's hooks ran under -p. --bare skips all of that discovery and is the documented recommendation for scripted calls, but it does not use your subscription login and needs an ANTHROPIC_API_KEY, so I did not run it.

--output-format takes text (the default), json (one result object with metadata) or stream-json (one event per line, used throughout Chapter 17). Here is what the json result of the smallest possible run contains, on this version:

The ones a script cares about, with their values from that run:

• result is the answer text. It is null when the run did not finish normally, as section 04 shows, so read it only after checking is_error.
• subtype and terminal_reason say why the run ended: success and completed here.
• total_cost_usd and num_turns let a script track spend and effort. The documentation calls the cost a client-side estimate that can differ from your bill.
• permission_denials lists calls that were refused, which Chapter 17 used to find hook and mode denials.

Prose is hard to parse. With --json-schema plus --output-format json, the answer arrives in a structured_output field that conforms to your schema. If the run ends without valid structured output, the field is simply absent, so a script must check for it before use (Source 1). Conforming to a schema says the answer has the right shape. It says nothing about whether it is true. So the script below asks Claude for the failing features, and then checks the answer against the file with jq:

Two runs. The first compares with the real file. The second compares the same kind of answer with an altered copy in which feature #7 is marked passing, to prove the gate can say no:

• The model was right both times, [6,7]. In the second run the ground truth was changed, and the gate reported MISMATCH and exited 4. That is the behaviour you want from a gate: it cares about the comparison, not about how confident the model sounded.
• The exit codes are yours. 3 means no structured output, 4 means a mismatch. A pipeline can branch on them or just treat any non-zero as failure.
• This pattern fits questions with a checkable answer. "Which tests failed?" can be checked against a test report. "Is this design good?" cannot, and no gate script will make it so.

Two flags put a ceiling on a run: --max-turns and --max-budget-usd. I hit both on purpose, and ran one invalid flag, to see what a script receives:

• Both caps give a non-zero exit code and is_error: true. The subtype tells them apart: error_max_turns and error_max_budget_usd.
• result is null. A script that pipes .result straight into a file would write the word null. Always check is_error first.
• Caps are checked after a step, not before it. With --max-turns 1 the run reports 2 turns, and a budget of $0.0005 stopped at $0.0016. Set a cap with margin, and treat it as "about this much", not "never more".
• An invalid flag fails before any API call, with a one-line message on stderr and exit 1. A failure inside a run, such as missing authentication, is printed as the result on stdout instead (Source 1).
• Killing a run: SIGTERM makes it exit with 143 and record no result for the turn in progress; SIGINT ends the turn first. I did not test either.

From 2.1.302 a -p run with no permission mode set starts in Manual mode, where a call that needs approval is denied unless something approves it, so a silent hang waiting for a prompt is not the failure to expect. A refused call shows up in the result's permission_denials, which is why a gate should look at it. Every sample in this guide used dontAsk plus a narrow --allowedTools, and the capstone in the next chapter shows what a denial looks like in a real task.

Chapter 24 proved a plugin loaded by reading the start-up event. The documentation turns that into a CI check: the event carries plugin_errors and mcp_server_errors, both omitted when empty. A bad entry does not stop the run, which "continues and exits cleanly", so without a check a broken configuration passes unnoticed (Source 1).

Three runs: the good plugin from Chapter 24, a plugin directory that does not exist, and an MCP entry with a url but no type:

The good plugin passes. The missing plugin is reported as path-not-found, with the path. The bad MCP entry is reported as url_missing_type with a message that says how to fix it. In both failing cases Claude Code itself exited cleanly; only the gate failed the build. That is the whole point of writing one.

The cheapest check never calls Claude. Several mistakes in this guide were mistakes in files: a skill whose frontmatter did not start on line 1 (Chapter 18), a misspelled key that is ignored silently, a plugin server with a relative path (Chapter 12). A script can find all three in milliseconds. This one uses only the Python standard library:

• Clean repository: zero findings, with the intentionally broken demos excluded.
• The two broken skills from Chapter 18 are both caught, with the reason: frontmatter not on line 1, and the misspelled descripton key that is "ignored silently".
• The Chapter 12 plugin is flagged for the relative server path. That rule encodes a plain fact about relative paths (they resolve against the process's working directory) and my reading of how plugin servers are launched; I never ran the old file to watch it fail.

It checks: valid JSON in settings files and that every hook script they name exists and is executable; SKILL.md and agent frontmatter (first line, required keys, known keys, name matching folder); .mcp.json entries; and plugin layout. The frontmatter reader is deliberately simple, not a YAML parser, and its key lists come from the documentation read for Chapters 18 and 20, so a newer Claude Code release can make them stale. Wire it into CI next to the hook tests, which now assert their exit codes and fail the run if one is wrong: