3.6 CI/CD Integration

What You Need to Know

Drop Claude Code into a CI/CD pipeline and it stops being an interactive developer tool and becomes an automated review and generation engine. The exam tests five concepts in this task statement, and the -p flag is the single most directly tested item (it’s Question 10 in the sample question set).

The -p Flag: Non-Interactive Mode

Claude Code defaults to interactive mode: it expects keyboard input and shows a conversational interface. A CI pipeline has no keyboard. Without the -p flag, the job hangs forever, waiting for input that never comes.

# WRONG — hangs in CI
claude "Analyse this pull request for security issues"

# CORRECT — runs non-interactively
claude -p "Analyse this pull request for security issues"

The -p flag (also --print) switches Claude Code to print mode: it processes the prompt, outputs the result to stdout, and exits. No interactive input required.

This one is pure memorisation. The exam shows a CI job hanging, logs of Claude waiting for input, and asks you to pick the fix. The answer is the -p flag. Not CLAUDE_HEADLESS=true (doesn’t exist). Not --batch (doesn’t exist). Not stdin redirection from /dev/null (doesn’t properly address Claude Code’s interactive mode).

Structured Output for CI

In CI, Claude Code’s output has to be machine-parseable. No human is reading it. Automated systems process it to post inline PR comments, update dashboards, or trigger downstream workflows.

Two flags work together:

--output-format json — wraps the run in a JSON envelope (result text, session ID, cost and usage metadata) instead of human-readable text
--json-schema — validates the agent’s final output against a JSON Schema (print mode only)

claude -p \
  --output-format json \
  --json-schema '{"type":"object","properties":{"findings":{"type":"array","items":{"type":"object","properties":{"file":{"type":"string"},"line":{"type":"integer"},"severity":{"type":"string"},"message":{"type":"string"}}}}}}' \
  "Review this PR for security issues"

The schema-conforming data lands in the envelope’s structured_output field — extract it with jq '.structured_output', not from the top level. That gives automated systems validated findings they can:

Parse programmatically
Post as inline PR comments at the exact file and line
Filter by severity for different notification channels
Track across review runs

Session Context Isolation

The same Claude session that generated code is less effective at reviewing its own changes. This isn’t a theoretical worry; it’s a measurable effect.

Why self-review is weaker:

When Claude generates code in a session, it builds up reasoning context: why it chose this approach, what tradeoffs it considered, what alternatives it rejected. Ask it to review the same code in the same session and it keeps all of that. It’s less likely to question decisions it already justified to itself.

The fix: independent review instances

Use a separate Claude Code invocation for review — one that has no access to the generation session’s reasoning context. The independent reviewer evaluates the code on its own merits, without the bias of prior justification.

# Step 1: Generate code (session A)
claude -p "Implement the authentication middleware"

# Step 2: Review code (session B — independent, no shared context)
claude -p "Review the authentication middleware for security issues, error handling gaps, and edge cases"

This concept connects to Domain 4 (multi-instance review architectures) and Domain 5 (context management). The exam tests it in CI/CD scenarios specifically.

Incremental Review Context

Automated reviews run on every push. Without context about previous reviews, each run analyses the entire PR from scratch, so it re-derives the same findings every time. A genuinely fixed issue drops out on its own, because the changed code no longer triggers it. The ones that keep coming back are the issues the developer saw and deliberately chose not to change; a context-free re-scan cannot tell those apart from new problems, so it flags them again on every push.

The fix: include prior review findings in context and instruct Claude to report only new or still-unaddressed issues.

claude -p \
  --output-format json \
  "Review this PR. Here are the findings from the previous review:
  ${PREVIOUS_FINDINGS}

  Report ONLY:
  1. New issues not in the previous findings
  2. Issues from the previous findings that are still present

  Do NOT re-report previous findings the developer has already reviewed and chosen not to act on."

Duplicate comments erode developer trust. If every push generates the same five comments regardless of whether the developer fixed the issues, developers stop reading the comments. Incremental review context preserves the signal-to-noise ratio.

CLAUDE.md for CI Context

When Claude Code runs in CI, it reads the project’s CLAUDE.md files exactly as it does interactively. So CLAUDE.md is how you feed project-specific context to a CI-invoked run:

Testing standards: what makes a valuable test, what patterns to follow, what to avoid
Available fixtures: which test fixtures exist, how to use them, what data they contain
Review criteria: what constitutes a critical finding vs a minor style issue
Existing test coverage: what is already covered, to avoid suggesting duplicate tests

Without this context in CLAUDE.md, CI-invoked test generation produces low-value boilerplate. With it, generated tests follow the team’s patterns and add genuine coverage.

# .claude/CLAUDE.md — CI-relevant section
## Testing Standards

- Tests must use the factory pattern from test/factories/ for data creation
- Integration tests connect to the test database via test/setup/db.ts
- Do not test private implementation details — test public API contracts
- Coverage target: 80% branch coverage for new code
- Available fixtures: test/fixtures/users.json, test/fixtures/orders.json

CLI Flags Reference

The -p flag is the most directly tested flag, but the exam also expects familiarity with the flags that shape a headless run: how output is formatted, which system prompt is used, and how permissions and tools are scoped. These flags work with claude -p in CI and with the interactive claude command.

System prompt flags. Claude Code provides four flags here, and the exam tests the append-versus-replace distinction:

Flag	Effect
`--system-prompt "<text>"`	Replaces the entire default system prompt
`--system-prompt-file <path>`	Replaces the default prompt with a file’s contents
`--append-system-prompt "<text>"`	Appends text to the default prompt
`--append-system-prompt-file <path>`	Appends a file’s contents to the default prompt

Append when Claude should stay a coding assistant that also follows your extra rules. Appending keeps the default tool guidance, safety instructions, and coding conventions, so you only supply what differs. Replace when the identity or permission model differs from Claude Code’s, like a non-coding agent in a pipeline no human watches. Replacing drops the entire default prompt, so you own everything the task still needs.

Headless output and limits (print mode).

Flag	Effect
`--output-format text\|json\|stream-json`	Output shape for `-p`; `json` and `stream-json` are machine-parseable
`--input-format text\|stream-json`	Input shape for `-p`
`--json-schema '<schema>'`	Schema-validated output for `-p`; with `--output-format json` it lands in the envelope’s `structured_output` field
`--max-turns <n>`	Cap the number of agentic turns, then exit

Permissions, tools, and context.

Flag	Effect
`--permission-mode <mode>`	Start in `default`, `acceptEdits`, `plan`, `auto`, `dontAsk`, `bypassPermissions`, or `manual` (an alias for `default`, v2.1.200+)
`--allowedTools "<rules>"`	Tools that run without a permission prompt, e.g. `"Bash(git diff *)" "Read"`
`--disallowedTools "<rules>"`	Deny rules; a bare tool name removes the tool from context entirely
`--tools "Bash,Edit,Read"`	Restrict which built-in tools are available at all
`--add-dir <path>`	Add a directory Claude may read and edit (grants file access, not configuration discovery)
`--model <alias\|name>`	Set the session model (`sonnet`, `opus`, or a full model name)

Session and start-up. -c / --continue resumes the most recent conversation in the current directory, and -r / --resume <id|name> resumes a specific session. --bare is minimal mode: it skips auto-discovery of hooks, skills, plugins, MCP servers, auto memory, and CLAUDE.md so scripted calls start faster, leaving Claude with the Bash and file read/edit tools only. Reach for --bare when you want a fast, predictable scripted run and don’t need project configuration loaded.

Providing Existing Tests to Avoid Duplication

When running test generation in CI, include existing test files in context. Without them, Claude Code may suggest tests that already exist, wasting developer review time. Including existing tests enables Claude to identify coverage gaps rather than duplicating existing scenarios.

Batch API vs Real-Time for CI Workflows

The Message Batches API offers 50% cost savings but has processing times up to 24 hours with no guaranteed latency SLA. This creates a clear decision boundary:

Workflow type	API choice	Reason
Pre-merge checks (blocking)	Real-time (synchronous)	Developers wait for results
Overnight technical debt reports	Batch API	Not time-sensitive, 50% savings
Weekly code audit	Batch API	Scheduled, latency-tolerant
Nightly test generation	Batch API	Runs overnight, reviewed next morning

Pre-merge checks are blocking workflows. Developers can’t merge until the check completes. The Batch API is unsuitable here because it gives no latency guarantee. The exam tests this distinction directly (Sample Question 11).

Exam Traps

Practice Scenario

A CI pipeline script runs claude with a prompt but the job hangs indefinitely. Logs show Claude Code is waiting for interactive input. What is the correct fix?

A. Add the -p flag so Claude Code runs in non-interactive print mode
B. Set the environment variable CLAUDE_HEADLESS=true before running the command
C. Redirect stdin from /dev/null to prevent interactive prompts
D. Add the –batch flag to enable batch processing mode

Answer & explanation

Correct: A

A — The -p (–print) flag runs Claude Code in non-interactive mode. It processes the prompt, outputs the result to stdout, and exits without waiting for user input. This is the documented approach for CI/CD integration.
B — CLAUDE_HEADLESS is not a real Claude Code environment variable. This option references a feature that does not exist.
C — Unix stdin redirection is a generic workaround that does not properly address Claude Code interactive mode. The -p flag is the correct, documented approach.
D — –batch is not a real Claude Code CLI flag. This option references a feature that does not exist.

Sources

Claude Code CLI Reference — Anthropic
Claude Certified Architect Foundations Exam Guide — Task Statement 3.6 — Anthropic
Claude Certified Architect Foundations Exam Guide — Sample Questions 10 and 11 — Anthropic
Anthropic Message Batches API Documentation — Anthropic

Exam Simulator

Six exam-style multiple-choice questions on CI/CD Integration. Pick an answer, then open the explanation.

Question 1

A CI pipeline script runs ‘claude “Analyse this PR”’ but the job hangs indefinitely. Logs show Claude Code is waiting for interactive input. What is the correct fix?

A. Add the –batch flag: claude –batch “Analyse this PR”
B. Set the environment variable CLAUDE_HEADLESS=true before running the command
C. Redirect stdin from /dev/null: claude “Analyse this PR” < /dev/null
D. Add the -p flag: claude -p “Analyse this PR” in CI

Answer & explanation

Correct: D

A is wrong: –batch is not a real Claude Code CLI flag. This option references a feature that does not exist.
B is wrong: CLAUDE_HEADLESS is not a real Claude Code environment variable. This option references a feature that does not exist.
C is wrong: Unix stdin redirection is a generic workaround that does not properly address Claude Code’s interactive mode. The -p flag is the correct, documented approach.
D is correct: The -p (–print) flag runs Claude Code in non-interactive mode. It processes the prompt, outputs the result to stdout, and exits without waiting for user input. This is the documented approach for CI/CD integration.

Question 2

A CI pipeline needs to post review findings as inline PR comments at specific file and line numbers. Which flags should be used with Claude Code?

A. –output-format json with –json-schema
B. –verbose and –line-numbers
C. –format markdown and –annotate
D. –output-format json alone, without any schema

Answer & explanation

Correct: A

A is correct: –output-format json produces JSON output, and –json-schema enforces a specific structure with file, line, severity, and message fields. This enables automated systems to parse findings and post them as inline PR comments at exact locations.
B is wrong: –verbose and –line-numbers are not valid Claude Code flags for structured output.
C is wrong: –format markdown and –annotate are not valid Claude Code flags.
D is wrong: While –output-format json produces JSON, without –json-schema the structure is not guaranteed to have the specific fields needed for inline PR commenting.

Question 3

A team runs Claude Code to generate authentication middleware, then in the same session asks Claude to review the generated code. The review finds no issues. A separate team member reviews the same code independently and finds three security gaps. Why did the self-review miss the issues?

A. The generation session used a less capable model than the review session
B. Claude Code cannot review code it generated due to a technical limitation
C. The session keeps its generation context and will not question itself
D. The self-review needs a more detailed prompt to find security issues

Answer & explanation

Correct: C

A is wrong: Both sessions use the same model. The issue is context bias, not model capability.
B is wrong: There is no technical limitation preventing self-review. The issue is effectiveness, not capability. Self-review works but is biased.
C is correct: The generation session built up reasoning context – why it chose this approach, what tradeoffs it considered, what alternatives it rejected. When asked to review, it retains that justification context and is less likely to question decisions it already rationalised.
D is wrong: A more detailed prompt does not remove the reasoning context bias. The fundamental issue is that the session cannot easily challenge its own prior reasoning.

Question 4

A CI review pipeline runs on every push. Developers complain that the same five issues are flagged on every push, even after they have addressed some of them. What is the correct fix?

A. Reduce the review frequency to once per day instead of every push
B. Pass prior findings in and ask only for new or unfixed issues
C. Filter the output to suppress findings older than 24 hours
D. Use a different review prompt that is less thorough

Answer & explanation

Correct: B

A is wrong: Reducing frequency does not fix the duplicate comment problem. The same issues would still appear each time the review runs.
B is correct: Including previous findings in context and instructing Claude to report only new or still-present issues prevents duplicate comments. This preserves the signal-to-noise ratio and maintains developer trust in the review system.
C is wrong: Age-based filtering is unreliable. An issue that was flagged yesterday and fixed today would still be suppressed. New issues might also be caught in the filter.
D is wrong: Making the review less thorough misses real issues. The problem is duplicate reporting, not over-detection.

Question 5

A team wants to use the Message Batches API for their pre-merge CI checks to save on costs. Is this appropriate?

A. No, the Batch API can take up to 24 hours and offers no latency SLA
B. Yes, the 50% cost savings justify using the Batch API for all CI workflows
C. Yes, as long as the team sets a timeout of 5 minutes on the batch request
D. No, the Batch API does not support code review tasks

Answer & explanation

Correct: A

A is correct: The Message Batches API has processing times up to 24 hours with no guaranteed latency SLA. Pre-merge checks are blocking workflows – developers cannot merge until the check completes. The Batch API is appropriate for non-blocking, latency-tolerant workloads like overnight technical debt reports or weekly audits.
B is wrong: Cost savings do not compensate for blocking developers who are waiting to merge. Pre-merge checks must complete promptly.
C is wrong: The Batch API does not support custom timeout settings. There is no mechanism to guarantee fast completion.
D is wrong: The Batch API can handle code review tasks. The issue is latency, not capability.

Question 6

CI-invoked Claude Code generates test files, but the tests use generic inline data instead of the team’s established factory functions and fixture files. What is the most likely cause?

A. Claude Code cannot access the test/factories/ directory in CI
B. CI-invoked Claude Code uses a stripped-down model that cannot generate sophisticated tests
C. The team’s testing standards, factory functions, and available fixtures are not documented in CLAUDE.md
D. The -p flag disables access to project configuration files

Answer & explanation

Correct: C

A is wrong: Claude Code in CI has the same file access as in interactive mode within the repository.
B is wrong: The same model runs in both interactive and CI modes. There is no stripped-down variant.
C is correct: Claude Code reads CLAUDE.md in CI just as in interactive mode. Without testing standards, factory function documentation, and fixture paths in CLAUDE.md, Claude Code has no context about the team’s patterns and falls back to generic boilerplate.
D is wrong: The -p flag only switches from interactive to print mode. It does not disable configuration file access. CLAUDE.md files are still read.