L3: CI/CD Integration and Session Isolation

CI/CD Integration and Session Isolation

Up to this point, we have treated Claude Code as a local pair programmer—a tool running on a developer's laptop. However, enterprise architecture requires automation. This lesson transitions Claude Code from an interactive terminal tool into an autonomous participant within Continuous Integration and Continuous Deployment (CI/CD) pipelines.

1. The Headless Execution Paradigm

By default, Claude Code runs a Read-Eval-Print Loop (REPL) that waits for a human to type a prompt and press Enter. In a CI/CD environment (like GitHub Actions, GitLab CI, or Jenkins), there is no human. The system must run headlessly.

Architectural Implementation: To execute Claude Code in a pipeline, you bypass the interactive prompt by passing instructions directly via CLI flags or standard input (e.g., claude --prompt "Review the recent git diff and summarize security vulnerabilities").
The "Auto-Accept" Risk: In local Plan Mode, Claude Code asks for human approval before modifying files. In CI/CD, you must pass an auto-approve flag to allow execution. This makes strict CLAUDE.md boundaries and tightly scoped tool permissions absolutely critical, as there is no human-in-the-loop to catch a hallucinated rm -rf.

2. The Necessity of Session Isolation

A CI/CD runner is often a shared or reused environment. If multiple automated jobs run Claude Code simultaneously, or if one job runs multiple distinct agentic tasks sequentially, Session Isolation becomes the most critical architectural requirement.

State Pollution: If Agent A (tasked with writing unit tests) and Agent B (tasked with writing deployment scripts) share the same underlying session memory, Agent B's context window will be polluted with Agent A's test logs. This causes severe hallucinations.
Architectural Solution: You must enforce isolation by dynamically generating unique Session IDs for every distinct CI/CD job. If utilizing temporary scratchpads or local memory files, the pipeline must ensure these files are wiped or stored in job-specific, ephemeral directories that are destroyed when the runner finishes.

3. The Generator vs. Reviewer Pattern

The most common enterprise architecture pattern for LLMs in CI/CD is the Generator vs. Reviewer pattern. This is an automated system of checks and balances.

Instead of one agent doing all the work, the pipeline orchestrates two completely isolated sessions:

The Generator Session: Triggered when a PR is opened. It is tasked with reading the PR, finding failing tests, and writing the code to fix them.
The Reviewer Session: Triggered after the Generator commits its changes. This session uses a completely different CLAUDE.md configuration (often locked down to strictly enforce corporate security and style guidelines). Its prompt is: "Critique this code. Do not write code. If it violates standards, fail the build."

Why isolate them? If the Reviewer shares a session with the Generator, it suffers from "confirmation bias." It remembers its own reasoning for writing the code and will blindly approve its own mistakes. Isolation forces a mathematically fresh evaluation.

4. Secret Management in Pipelines

When Claude Code runs locally, it relies on your personal OAuth login. In CI/CD, it requires a Machine User or a direct API key.

The Anti-Pattern: Never store the ANTHROPIC_API_KEY in the repository or in a plaintext configuration file.
The Enterprise Pattern: Use your Git provider's secure Secrets manager (e.g., GitHub Secrets). Inject the key into the CI runner's environment variables strictly at runtime.
MCP Server Scope in CI: If your pipeline agent uses MCP servers (e.g., to read a Jira ticket to verify PR requirements), the CI/CD environment must only be injected with a strictly scoped, read-only Jira token. Never reuse your broad production database credentials in a CI/CD runner.

5. Automated Escalation (Failing the Build)

In a local environment, if Claude Code gets stuck, it asks the developer for help. In a CI/CD pipeline, an agent that gets stuck in an infinite loop will consume all your runner minutes and rack up massive token bills.

Hard Timeouts: The pipeline architecture must enforce strict timeouts (e.g., maximum 10 minutes per agentic job).
Deterministic Exits: Instruct the agent via CLAUDE.md on how to fail gracefully. "If you cannot resolve the test failures within 3 attempts, do NOT keep guessing. Exit with a non-zero status code (e.g.,exit 1) and write a summary of the failure to pr_comment.md." * By exiting with a non-zero code, the agent correctly triggers the CI/CD pipeline to block the Pull Request, while leaving a helpful artifact for the human developer to read.