Claude Code in CI: Running Agentic Code Review, Test Generation, and Auto-Fix on Every Pull Request

Why Agentic Code Review in CI Changes Everything

Most CI failures waste hours on manual intervention because traditional bots flag problems but never fix them. Developers open a pull request, the linter fails, tests break, and someone must context-switch from their current work to diagnose and patch the issue. This context-switching compounds across teams until the cost of maintaining CI hygiene exceeds the value it provides.

flowchart LR
    A("Developer opens PR") --> B("CI runs lint and tests")
    B --> C("Failures appear in logs")
    C --> D("Developer context-switches to fix")
    D --> E("Manual review required anyway")
    style C stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7
    style E stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7

Claude Code running in auto mode solves this by operating as an autonomous agent inside the CI pipeline. When a pull request triggers the workflow, Claude Code reviews the diff, generates missing tests, attempts to fix failures, and posts structured feedback as review comments—all without human intervention. The developer receives actionable fixes instead of error logs.

flowchart LR
    A("Developer opens PR") --> B("Claude Code reviews diff")
    B --> C("Auto-generates tests")
    C --> D("Auto-fixes failures")
    D --> E("Posts review comments with patches")
    style C stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px
    style D stroke:#34d399,fill:#0b3b2e,color:#d1fae5
    style E stroke:#34d399,fill:#0b3b2e,color:#d1fae5

This distinction is critical. Traditional CI bots detect and report. Agentic CI detects, repairs, and documents. The ROI appears in two places: reduced time-to-merge for routine issues and preserved cognitive capacity for architectural decisions that actually require human judgment.

Key Takeaways

• Claude Code in auto mode runs unattended in CI pipelines with a safety classifier blocking dangerous commands before execution.
• Agentic CI performs code review, test generation, and auto-fix in a single workflow—eliminating the manual context-switch loop.
• Production deployments require cost controls (token budgets per PR), scoped file permissions, and exit conditions to prevent runaway execution.
• GitHub Actions, GitLab CI, and Azure DevOps all support Claude Code integration through environment variables and secrets management.
• The pattern that works now is scoped, single-responsibility agents—one for review, one for test generation, one for auto-fix—not a single agent attempting all tasks.

Claude Code in Auto Mode: Running Unattended in CI Pipelines

Auto mode enables Claude Code to execute commands without interactive confirmation. The agent receives a task, plans a sequence of operations, and runs them to completion while a classifier model reviews each command for scope escalation or filesystem access beyond the defined boundaries. This safety layer matters in CI because the agent operates with repository write access and environment secrets.

flowchart TD
    A("PR triggers workflow") --> B("Claude Code receives task")
    B --> C("Agent plans command sequence")
    C --> D("Classifier reviews each command")
    D --> E{"Command safe?"}
    E -->|Yes| F("Execute command")
    E -->|No| G("Block and log violation")
    F --> H("Collect output")
    H --> I{"Task complete?"}
    I -->|No| C
    I -->|Yes| J("Post results to PR")
    style D stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px
    style G stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7
    style J stroke:#34d399,fill:#0b3b2e,color:#d1fae5

The failure mode here is subtle but expensive. Without auto mode, Claude Code pauses for interactive approval on every command. In CI, no terminal exists for interaction, so the workflow hangs until timeout. With auto mode enabled, the agent proceeds to completion or hits a safety block, either of which produces a usable outcome for the pull request.

Configuring auto mode requires setting the CLAUDE_AUTO_MODE environment variable and defining a permission scope in the workflow manifest. The scope restricts which files the agent can read or modify. A code review agent should see the entire diff but write only to a temporary comment file. A test generation agent needs read access to source files and write access to test directories.

Setting Up Claude Code for Pull Request Reviews

The entry point for agentic CI is a GitHub Actions workflow that triggers on pull request events. The workflow checks out the repository, installs Claude Code, and invokes it with a task description tied to the specific PR diff.

// .github/workflows/claude-review.yml
name: Claude Code Review
 
on:
  pull_request:
    types: [opened, synchronize]
 
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Full history for accurate diffs
      
      - name: Install Claude Code
        run: npm install -g @anthropic/claude-code
      
      - name: Run Code Review
        env:
          CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}
          CLAUDE_AUTO_MODE: true
          CLAUDE_SCOPE: "read:**/*.{ts,tsx,js,jsx},write:.claude/review.md"
          PR_NUMBER: ${{ github.event.pull_request.number }}
          BASE_SHA: ${{ github.event.pull_request.base.sha }}
          HEAD_SHA: ${{ github.event.pull_request.head.sha }}
        run: |
          claude --task "Review the diff between $BASE_SHA and $HEAD_SHA. 
          Focus on type safety, error handling, and performance implications. 
          Write findings to .claude/review.md with specific line references and suggested fixes."
      
      - name: Post Review
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = fs.readFileSync('.claude/review.md', 'utf8');
            await github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: review
            });

This configuration separates concerns cleanly. The CLAUDE_SCOPE variable prevents the agent from modifying source files during review. The task description anchors the agent's focus on specific quality dimensions. The GitHub Script action posts results as a comment, preserving them in the PR timeline for future reference.

The review step runs in parallel with existing CI checks. If the build fails, Claude Code still performs its review based on the diff. If tests fail, a separate workflow handles auto-fix. This parallel execution reduces total pipeline time compared to sequential stages.

Auto-Generating Tests and Auto-Fixing Failures in CI

Test generation and auto-fix require write access to the repository, which introduces risk if the agent produces malformed code. The mitigation strategy is a two-phase workflow: the agent writes to a feature branch, then a human reviews the agent's commit before merging to the target branch.

// .github/workflows/claude-auto-fix.yml
name: Claude Auto-Fix
 
on:
  pull_request:
    types: [opened, synchronize]
  workflow_run:
    workflows: ["CI"]
    types: [completed]
    branches-ignore:
      - claude-auto-fix-*
 
jobs:
  fix:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    permissions:
      contents: write
      pull-requests: write
    
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.ref }}
          token: ${{ secrets.GITHUB_TOKEN }}
      
      - name: Create Fix Branch
        run: |
          FIX_BRANCH="claude-auto-fix-${{ github.event.pull_request.number }}-$(date +%s)"
          git checkout -b "$FIX_BRANCH"
          echo "FIX_BRANCH=$FIX_BRANCH" >> $GITHUB_ENV
      
      - name: Install Dependencies
        run: npm ci
      
      - name: Run Tests to Capture Failures
        id: test
        continue-on-error: true
        run: npm test 2>&1 | tee test-output.log
      
      - name: Claude Auto-Fix
        if: steps.test.outcome == 'failure'
        env:
          CLAUDE_API_KEY: ${{ secrets.CLAUDE_API_KEY }}
          CLAUDE_AUTO_MODE: true
          CLAUDE_SCOPE: "read:**/*,write:src/**/*.{ts,tsx,test.ts,test.tsx}"
          CLAUDE_TOKEN_BUDGET: 50000
        run: |
          claude --task "Analyze test-output.log and fix the failing tests. 
          Generate missing tests for any new functions in the diff that lack coverage. 
          Ensure all fixes maintain type safety and existing test patterns. 
          Commit changes with a descriptive message."
      
      - name: Push Fix Branch
        run: |
          git config user.name "claude-code[bot]"
          git config user.email "claude-code[bot]@users.noreply.github.com"
          git push origin "$FIX_BRANCH"
      
      - name: Create PR for Fixes
        uses: actions/github-script@v7
        with:
          script: |
            await github.rest.pulls.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `🤖 Auto-fix for PR #${{ github.event.pull_request.number }}`,
              head: process.env.FIX_BRANCH,
              base: '${{ github.event.pull_request.head.ref }}',
              body: `Automated fixes generated by Claude Code for failing tests in PR #${{ github.event.pull_request.number }}.
              
              Review the changes carefully before merging.`
            });

The CLAUDE_TOKEN_BUDGET environment variable caps the agent's total token usage for this task. Without this limit, a runaway loop—where the agent generates code that introduces new failures, then attempts to fix those failures—can consume quota rapidly. A budget of 50,000 tokens typically covers diagnosis, code generation, and verification for most test suites.

The pattern here is defensive. The agent writes to a separate branch, never directly to the PR branch. This creates a manual approval gate: a developer reviews the auto-fix PR, confirms the changes are correct, then merges them into the original PR. If the auto-fix introduces regressions, the developer closes the auto-fix PR and addresses the issue manually.

For test generation specifically, the task description should reference the existing test suite's patterns. If the project uses Vitest with a particular assertion style, the prompt must include an example. Without this anchoring, Claude Code defaults to generic Jest patterns that may not match the project's conventions.

Comparison: Claude Code vs Traditional CI Bots vs Manual Review

Traditional CI bots detect violations but never repair them. Manual review catches issues but scales poorly as teams grow. Claude Code occupies a middle ground: it automates repairs for mechanical issues while flagging complex problems for human review.

flowchart LR
    A("Code change submitted") --> B{"Analysis approach"}
    
    subgraph Traditional["Traditional CI Bot"]
        C("Lint and test") --> D("Report failures in logs")
        D --> E("Developer must context-switch to fix")
    end
    
    subgraph Agentic["Claude Code in CI"]
        F("Lint, test, and review") --> G("Auto-fix mechanical issues")
        G --> H("Post structured review with patches")
    end
    
    subgraph Manual["Manual Code Review"]
        I("Human reviewer analyzes diff") --> J("Requests changes in comments")
        J --> K("Developer implements feedback")
    end
    
    B --> Traditional
    B --> Agentic
    B --> Manual
    
    style E stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7
    style H stroke:#34d399,fill:#0b3b2e,color:#d1fae5
    style K stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7

The implication here is that agentic CI does not replace human review for architectural decisions, security boundaries, or product requirements. It replaces the rote work of fixing lint errors, adding missing null checks, and generating boilerplate tests. The time savings compound when a team merges dozens of PRs per day.

Traditional bots excel at consistency. They enforce style rules without fatigue. Agentic CI excels at remediation. It applies fixes that follow the same patterns a human would use, but without the context-switching cost. Manual review excels at judgment. A human catches the security implication of a seemingly innocuous change that no static analysis tool flags.

The effective pattern combines all three. Traditional bots run first as a fast gate. If they fail, Claude Code attempts auto-fix. If auto-fix succeeds, the PR proceeds to manual review for non-mechanical concerns. If auto-fix fails, the developer receives both the bot's report and Claude's analysis of why the fix did not converge.

Production Patterns: Cost Control, Scoped Permissions, and Safety Classifiers

Deploying agentic CI in production requires three controls: token budgets to prevent runaway costs, scoped file permissions to limit blast radius, and safety classifiers to block dangerous operations.

flowchart LR
    A("PR triggers Claude Code") --> B("Check token budget")
    B --> C{"Budget remaining?"}
    C -->|No| D("Skip execution and log warning")
    C -->|Yes| E("Apply scoped permissions")
    E --> F("Execute task with classifier active")
    F --> G{"Command flagged?"}
    G -->|Yes| H("Block and report violation")
    G -->|No| I("Execute and decrement budget")
    I --> J{"Task complete?"}
    J -->|No| B
    J -->|Yes| K("Post results to PR")
    style D stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7
    style F stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px
    style H stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7
    style K stroke:#34d399,fill:#0b3b2e,color:#d1fae5

Token budgets sit at the repository level or per-PR level depending on billing constraints. A per-repository monthly budget prevents a single malicious or misconfigured PR from exhausting the organization's quota. A per-PR budget ensures fair resource distribution when multiple PRs arrive simultaneously. The tradeoff is complexity: per-PR budgets require state tracking across workflow runs, typically stored in repository secrets or a database.

Scoped permissions use glob patterns to define read and write boundaries. A review agent needs read:**/* but write:.claude/review.md. A test generation agent needs read:src/**/*,read:tests/**/* and write:tests/**/*.test.ts. A refactoring agent needs broader write access, so its budget should be lower and its outputs should always land on a review branch.

Safety classifiers run before command execution. The classifier model evaluates whether a command attempts to escalate privileges, access network resources, or modify files outside the declared scope. If the classifier flags a command, the agent receives an error and must choose an alternative approach. This matters because prompts can contain subtle injection attacks that trick the agent into running curl or rm -rf.

The failure mode developers encounter most often is scope misconfiguration. If the scope is too narrow, the agent cannot complete its task and the workflow fails silently. If the scope is too broad, the agent might modify unrelated files while attempting to fix a localized issue. The solution is a dry-run mode where Claude Code logs its intended operations without executing them, allowing developers to verify scope correctness before enabling auto mode.

For teams managing multiple repositories, a shared workflow configuration template reduces drift. The template defines standard scopes, budgets, and task descriptions. Individual repositories override specific values through repository variables. This centralization prevents the scenario where one team discovers a critical safety improvement but other teams continue running vulnerable configurations.

Real-World CI Integration: GitHub Actions, GitLab CI, and Azure DevOps

GitHub Actions provides the most straightforward integration because it natively supports secrets, matrix builds, and reusable workflows. The workflow manifest shown earlier runs on GitHub's hosted runners, but teams with compliance requirements can use self-hosted runners with pre-installed Claude Code binaries.

flowchart LR
    A("Developer pushes to PR") --> B{"CI Platform"}
    
    subgraph GitHub["GitHub Actions"]
        C("Trigger on pull_request event") --> D("Check out repo with full history")
        D --> E("Set CLAUDE_API_KEY from secrets")
        E --> F("Run Claude Code with scoped task")
    end
    
    subgraph GitLab["GitLab CI"]
        G("Trigger on merge_request event") --> H("Use Docker image with Claude CLI")
        H --> I("Pass credentials via CI_JOB_TOKEN")
        I --> J("Run Claude Code in Docker container")
    end
    
    subgraph Azure["Azure DevOps"]
        K("Trigger on PR created") --> L("Use pipeline variables for secrets")
        L --> M("Install Claude Code in pipeline step")
        M --> N("Run task and publish results")
    end
    
    B --> GitHub
    B --> GitLab
    B --> Azure
    
    style F stroke:#34d399,fill:#0b3b2e,color:#d1fae5
    style J stroke:#34d399,fill:#0b3b2e,color:#d1fae5
    style N stroke:#34d399,fill:#0b3b2e,color:#d1fae5

GitLab CI requires a Docker image containing the Claude Code binary because GitLab's runners do not persist global npm installations between jobs. The recommended approach is a custom Docker image based on node:20-alpine with Claude Code pre-installed. This image then appears in the .gitlab-ci.yml configuration:

# .gitlab-ci.yml
claude-review:
  image: registry.gitlab.com/yourorg/claude-code:latest
  stage: review
  only:
    - merge_requests
  script:
    - export CLAUDE_API_KEY=$CLAUDE_API_KEY_SECRET
    - export CLAUDE_AUTO_MODE=true
    - export CLAUDE_SCOPE="read:**/*.{ts,tsx,js,jsx},write:.claude/review.md"
    - claude --task "Review the merge request diff for type safety and error handling. Write findings to .claude/review.md."
    - |
      curl --request POST \
        --header "PRIVATE-TOKEN: $CI_JOB_TOKEN" \
        --form "body=<.claude/review.md" \
        "$CI_API_V4_URL/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes"

Azure DevOps uses pipeline variables for secrets and supports both YAML and classic editor pipelines. The YAML approach offers version control for pipeline definitions:

# azure-pipelines.yml
trigger:
  - none
 
pr:
  branches:
    include:
      - main
      - develop
 
pool:
  vmImage: 'ubuntu-latest'
 
steps:
  - checkout: self
    fetchDepth: 0
  
  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'
  
  - script: npm install -g @anthropic/claude-code
    displayName: 'Install Claude Code'
  
  - script: |
      export CLAUDE_API_KEY=$(CLAUDE_API_KEY)
      export CLAUDE_AUTO_MODE=true
      export CLAUDE_SCOPE="read:**/*.{ts,tsx,js,jsx},write:.claude/review.md"
      claude --task "Review PR diff focusing on async error handling and null safety. Output to .claude/review.md."
    displayName: 'Run Claude Code Review'
  
  - task: GitHubComment@0
    inputs:
      gitHubConnection: 'github-connection'
      repositoryName: '$(Build.Repository.Name)'
      id: $(System.PullRequest.PullRequestNumber)
      comment: |
        $(cat .claude/review.md)

The distinction across platforms matters for teams operating in polyglot environments. GitHub Actions provides the richest ecosystem of pre-built actions for posting comments, creating issues, and managing labels. GitLab CI offers tighter integration with GitLab's built-in code review features. Azure DevOps integrates with enterprise compliance tooling and supports complex approval workflows.

Credential management differs by platform but follows a common pattern: store the Claude API key in the platform's secrets manager, inject it as an environment variable at runtime, and never log it or write it to disk. For organizations with secret rotation policies, the integration should support reading from an external vault like HashiCorp Vault or AWS Secrets Manager rather than static platform secrets.

The Future of Agentic CI: What Works Now and What to Avoid

The pattern that works now is scoped, single-responsibility agents. One agent performs code review and posts comments. Another agent generates tests. A third agent attempts auto-fix for specific failure classes. These agents run independently, each with its own token budget and permission scope.

What to avoid: a single monolithic agent that attempts all tasks. The failure mode is cascading complexity. If the agent's review task fails, its test generation task never runs. If test generation consumes the entire token budget, auto-fix never executes. The result is unpredictable outcomes that make debugging CI failures harder than before Claude Code existed.

The emerging pattern for 2026 is declarative agent orchestration. Instead of writing imperative task descriptions, developers declare desired outcomes in a manifest: "All new functions must have tests. All failing tests must auto-fix. All PRs must have a review comment." The orchestration layer decides which agents to invoke, in what order, with what budgets. This declarative approach reduces configuration drift and makes agent behavior auditable.

Another promising direction is cost-aware scheduling. When a PR arrives, the orchestration layer estimates token costs for each agent based on diff size and historical usage patterns. If the estimated cost exceeds the per-PR budget, the orchestration layer selects a subset of agents to run or requests human approval to increase the budget. This prevents the scenario where a 5,000-line refactor consumes a week's worth of quota in a single workflow run.

Developers should avoid using agentic CI for architectural reviews or security audits without human supervision. Claude Code excels at detecting type errors, missing null checks, and inconsistent patterns. It cannot assess whether a database schema migration will cause downtime or whether an API change breaks backward compatibility with mobile clients. These concerns require human judgment informed by system-wide context that no agent currently possesses.

Teams adopting agentic CI should start with code review and test generation in non-critical repositories. Measure the accuracy of Claude's suggestions, the percentage of auto-fixes that merge without modification, and the reduction in time-to-merge. Use these metrics to calibrate token budgets and scope permissions before expanding to production repositories. The ROI becomes clear within a few dozen PRs: less time spent on mechanical fixes, more time available for design discussions.

Frequently Asked Questions

How much does running Claude Code in CI cost per pull request?

Cost depends on diff size, task complexity, and the model tier. For a typical PR with 200 lines changed, a code review task consumes approximately 5,000-10,000 tokens (input and output combined), which costs $0.15-$0.30 on Claude 3.5 Sonnet. Test generation and auto-fix tasks are more expensive, often reaching 20,000-50,000 tokens ($0.60-$1.50) for complex changes. Teams should set per-PR budgets and monitor actual usage to optimize costs.

Can Claude Code auto-fix security vulnerabilities detected by static analysis?

Claude Code can apply patches for known vulnerability patterns when given the static analysis report and access to the affected files. However, it should not be the sole mechanism for security fixes. The recommended pattern is: static analysis detects the issue, Claude Code generates a proposed patch, a human security engineer reviews the patch before merge. This prevents the scenario where the agent introduces a different vulnerability while fixing the original one.

What happens if Claude Code generates incorrect code in an auto-fix workflow?

The two-phase workflow (agent writes to a feature branch, human reviews before merge) prevents incorrect code from reaching the target branch. If the auto-fix introduces regressions, the developer closes the auto-fix PR and addresses the issue manually. Additionally, the CI pipeline runs tests against the auto-fix branch before creating the PR, so most regressions are caught automatically.

How do you prevent Claude Code from exhausting API quota during a spike in pull requests?

Implement rate limiting at the workflow level using a job concurrency group. GitHub Actions supports concurrency keys that queue jobs when too many run simultaneously. Set a global concurrency limit across all Claude Code workflows to cap parallel executions. For example, concurrency: claude-code-${{ github.repository }} ensures only one Claude workflow runs at a time per repository.

Does Claude Code work with monorepos containing multiple languages?

Yes, but scope configuration becomes more complex. Define separate scopes for each language: read:packages/typescript/**/*,write:packages/typescript/tests/**/*.test.ts for TypeScript, read:packages/python/**/*,write:packages/python/tests/**/*_test.py for Python. Use separate workflows or conditional steps to invoke language-specific agents. The Claude API itself is language-agnostic; the agent adapts to the patterns it observes in the codebase.

That covers the essential patterns for running Claude Code in CI. Apply these in production and the difference will be immediate: fewer context switches, faster PR merges, and preserved cognitive capacity for the architectural decisions that actually require human insight.