Integrate Claude Code into CI/CD pipelines

Claude Code is interactive by default: run bare claude "..." and it opens a session that can pause to ask for confirmation or more input. In a CI runner there is no human to answer, so that pause becomes a hang, the job sits waiting on stdin until it times out. This is the single most common CI integration failure.

The fix is the -p flag (long form --print). It runs Claude Code in non-interactive (print) mode: it takes the prompt, does the work, writes the result to stdout, and exits with a status code. No session, no prompt for input, no hang. That exit-and-print behavior is exactly what a pipeline step needs.

claude -p "Analyze this pull request for security issues"

The exam leans hard on distractors here. CLAUDE_HEADLESS=true is not a real environment variable, and --batch is not a real Claude Code flag (batching is a Message Batches API concept from Domain 4, unrelated to the CLI). Redirecting stdin from /dev/null is a Unix workaround that does not properly address Claude Code's non-interactive mode. The one correct answer is -p / --print. You can still feed content in by piping on stdin, for example git diff origin/main | claude -p "Review this diff".

A CI step needs structured output, not prose, so downstream tooling can turn findings into inline PR comments. Two flags give you that:

• --output-format json switches stdout from conversational text to a JSON document.
• --json-schema <file> constrains the output to a schema you supply, so every run produces the same predictable shape (location, issue, severity, suggested fix) that your posting script can rely on.

git diff origin/main | claude -p "Review this diff. Report bugs and security issues only." \
  --output-format json --json-schema review-findings.schema.json

With a guaranteed shape, the next pipeline step parses the JSON and posts each finding as an inline comment on the exact file and line. Never scrape prose output with regex, it breaks the moment the wording changes. This is the same reliability principle as tool_use with a JSON schema from Domain 4, applied to the CLI: constrain the output shape so automation can trust it.

A CI-invoked Claude Code run is headless and short-lived, so how does it know your team's testing standards, which fixtures exist, or what counts as a valuable finding? The answer is CLAUDE.md. When Claude Code runs inside the checked-out repo, it loads the project's CLAUDE.md automatically, the same file that guides interactive sessions. That makes CLAUDE.md the mechanism for injecting project context into automated runs.

For a review job, document the review criteria: which categories to flag (bugs, security) and which to skip (minor style), plus the severity definitions. For a test-generation job, document testing standards, what makes a test valuable, and the available fixtures and helpers.

This context measurably improves output quality and, crucially, reduces low-value output. Without it, generated tests trend toward trivial or redundant cases and reviews produce noise. Because CLAUDE.md is committed to the repo, it is shared across the whole team and every CI run, exactly the consistency you want from automated behavior. Tightening CLAUDE.md is often how you cut false positives without touching the pipeline itself.

When Claude generates code, it accumulates reasoning about why its solution is correct. Ask that same session to review its own output and it carries that reasoning forward, it is primed to defend its choices rather than question them, so it misses subtle bugs. This is the self-review limitation (Domain 4.6).

The CI pattern that sidesteps it is session context isolation: run the review as a fresh, independent Claude Code invocation that has no memory of how the code was produced. A clean instance sees only the diff and the review criteria, so it evaluates the change on its merits and catches issues the author-instance would rationalize away.

In practice this is natural in CI, the review job is a separate claude -p process from whatever generated the code (which may not have been Claude at all). The takeaway for the exam: prefer an independent review instance over instructing a model to 'double-check its own work,' and do not assume a larger context window or extended thinking substitutes for a genuinely independent reviewer.

CI reviews re-run on every new commit pushed to a PR. A naive setup reviews the full diff each time and re-posts every finding, so the same comment piles up on each push and buries the new information. Developers stop reading.

The fix is to make the review idempotent across runs: include the prior review findings in the context of the re-run and instruct Claude to report only issues that are new or still unaddressed, suppressing anything already raised and anything the latest commit resolved. You feed the previous findings, which you saved as JSON from the last run, back into the prompt as known state.

The result is that each push adds only the delta, new problems and unresolved ones, instead of a growing wall of duplicate comments. This is a context-management move: the prior findings are state you carry forward so the model can reason about what has changed rather than starting from a blank slate each time.

For a test-generation job the analogous trap is regenerating tests that already exist. If Claude only sees the source file, it will happily propose tests for scenarios your suite already covers, adding noise and maintenance burden.

Provide the existing test files in the context of the generation request. With visibility into current coverage, Claude proposes tests for the gaps, untested branches and missing edge cases, rather than duplicating scenarios already handled. Combine this with the testing standards and fixtures documented in CLAUDE.md and the generated tests both match house style and reuse existing fixtures instead of inventing parallel ones.

The pattern generalizes across CI jobs: whether reviewing or generating, giving the model what already exists (prior findings, current tests) is what lets it produce only the incremental, valuable output rather than redundant bulk.