Claude Code CI/CD Setup: Safe GitHub Actions for PRs, Deploys, and Rollback

Asking Claude Code to “make CI/CD” is easy. Getting a workflow that is safe enough for production is the harder part. A useful pipeline must stop bad pull requests, avoid leaking secrets, separate staging from production, leave humans in charge of release approval, and make rollback boring.

This guide treats Claude Code as a CI/CD design partner, not a YAML vending machine. CI means continuous integration: lint, type checks, tests, and builds run whenever code changes. CD means continuous delivery or deployment: verified changes move into an environment. A gate is a condition that must pass before the next job runs. Secrets are private values such as API keys. OIDC is the short-lived identity flow that avoids long-lived cloud keys in GitHub Secrets.

Keep the official docs open while adapting the examples: Claude Code GitHub Actions, GitHub Actions workflow syntax, GITHUB_TOKEN permissions, GitHub Secrets, and GitHub Environments. The examples below use GitHub-hosted runners and the current major versions actions/checkout@v6 and actions/setup-node@v6 as of June 3, 2026. If you use self-hosted runners, confirm runner compatibility before upgrading.

Set the Automation Boundary First

Before writing YAML, decide what Claude Code may automate and what remains a human decision. Claude Code can inspect a repository, propose workflow files, read failure logs, and suggest fixes. It should not silently decide production release policy, widen token permissions, expose secrets, or run untrusted pull request code with privileged events.

Area	Good Claude Code task	Human-owned decision
PR checks	Generate lint, test, typecheck, and build jobs	Required checks and merge rules
PR review	Point out risky diffs and missing tests	Whether to accept the change
Deployment	Draft staging and production workflows	Approval policy and secret scope
Recovery	Summarize logs and propose rollback steps	Whether to rollback production

Use a constrained prompt before asking for files:

Design CI/CD for this repository.
The goals are pull request quality gates, staging deployment, Claude Code review, and production rollback.

Constraints:
- Use least-privilege GITHUB_TOKEN permissions per job.
- Do not use secrets on forked pull requests.
- If pull_request_target is suggested, explain why PR head code is not checked out.
- Put production deployment behind a GitHub Environment approval.
- Never print ANTHROPIC_API_KEY, DEPLOY_TOKEN, or other secret values.
- Produce workflow YAML that can be placed under .github/workflows/.

End with failure cases, verification commands, and rollback steps.

That prompt creates a harness, meaning a safe operating frame for the agent. For persistent project rules, put the same boundaries into CLAUDE.md; the CLAUDE.md best practices guide shows how to keep those rules useful instead of vague.

Use Case 1: Pull Request Quality Gate

The first workflow should stop unsafe or broken code before merge. This example runs lint, type checks, tests, and a build. It uses a Node.js matrix so the project is checked on Node 22 and 24.

# .github/workflows/ci.yml
name: ci

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  test:
    name: test-node-${{ matrix.node-version }}
    runs-on: ubuntu-latest
    timeout-minutes: 15
    strategy:
      fail-fast: false
      matrix:
        node-version: [22, 24]
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: ${{ matrix.node-version }}
          cache: npm

      - run: npm ci
      - run: npm run lint --if-present
      - run: npm run typecheck --if-present
      - run: npm test -- --runInBand

  build:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    needs: test
    steps:
      - uses: actions/checkout@v6

      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm run build

This is copy-paste runnable for a typical Node project with npm test and npm run build. The lint and typecheck steps use --if-present so the first setup does not fail on missing scripts. In a mature repository, ask Claude Code to inspect package.json and remove any fake gates. A CI step that quietly does nothing is worse than no step because it creates false confidence.

For test depth, pair this with Claude Code testing strategies. CI does not invent good tests; it enforces the tests you choose.

Use Case 2: Read-Only Claude Code PR Review

Claude Code can review pull requests for risky workflow changes, missing tests, secret exposure, and unrelated edits. Start with read-only review comments before allowing automated edits.

# .github/workflows/claude-pr-review.yml
name: claude-pr-review

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

permissions:
  contents: read
  pull-requests: write
  issues: write

concurrency:
  group: claude-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    if: >
      github.event.pull_request.draft == false &&
      github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v6
        with:
          persist-credentials: false

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          github_token: ${{ secrets.GITHUB_TOKEN }}
          prompt: |
            Review this pull request as a CI/CD safety reviewer.
            Focus on GitHub Actions permissions, secrets exposure, test coverage,
            deployment gates, rollback risk, and unrelated file changes.
            Do not edit files. Leave concise review comments with evidence.
          claude_args: |
            --max-turns 4

The fork guard matters: github.event.pull_request.head.repo.full_name == github.repository prevents this secret-backed workflow from running on outside forks. If you need external contributor coverage, split the design into a secret-free static workflow and a manually approved privileged workflow.

Be careful with pull_request_target. It runs in the context of the base repository, so it can see more privilege than a normal pull request workflow. If Claude Code suggests it, require an explanation of what code is checked out, whether secrets are visible, and why a safer event is not enough. For a deeper safety checklist, read Claude Code security best practices and Claude Code Git workflow.

Use Case 3: Staging and Production Deploy Gates

A practical CD flow sends main to staging automatically, then requires a manual production run and a GitHub Environment approval. Put production secrets in the production Environment, not in repository-wide secrets that every workflow can approach.

# .github/workflows/deploy.yml
name: deploy

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  deployments: write

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run build

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    timeout-minutes: 10
    environment: staging
    env:
      APP_ENV: staging
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run deploy:staging

  deploy-production:
    if: github.event_name == 'workflow_dispatch'
    needs: deploy-staging
    runs-on: ubuntu-latest
    timeout-minutes: 10
    environment: production
    env:
      APP_ENV: production
      DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm
      - run: npm ci
      - run: npm run deploy:production

On push, the workflow reaches staging. Production runs only through workflow_dispatch, and the production Environment can require reviewers. This prevents the common failure where merging to main immediately publishes a bad build to customers.

Use Case 4: Recovery and Rollback

CI/CD needs a failure path. Write rollback before the first production incident. Claude Code can help analyze logs, but the rollback button should still be a human decision.

# .github/workflows/rollback-production.yml
name: rollback-production

on:
  workflow_dispatch:
    inputs:
      target_sha:
        description: "Commit SHA to redeploy to production"
        required: true
        type: string

permissions:
  contents: read
  deployments: write

jobs:
  rollback:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    environment: production
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ inputs.target_sha }}

      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm run build
      - run: npm run deploy:production

Ask Claude Code to review deploy.yml and rollback-production.yml together. The useful review questions are: can an older commit still build, are database migrations reversible, do environment variables differ between staging and production, and can the team identify the currently deployed SHA? For log triage habits, use the build error triage loop.

Concrete Pitfalls

The first pitfall is overbroad permissions. permissions: write-all may make a workflow pass, but it also expands the blast radius. Start with contents: read, then add only the permissions the job can explain.

The second pitfall is logging secrets. Never print DEPLOY_TOKEN or ANTHROPIC_API_KEY. Ask Claude Code to verify secret names and environment scope without exposing values.

The third pitfall is fake CI. --if-present is useful during the first migration, but it should not hide missing tests forever. Make the final gate explicit.

The fourth pitfall is letting Claude Code fix a failed pipeline without context. Give it the first failing command, the first relevant error line, the expected behavior, and the command you used locally. Narrow context beats a giant log dump.

Monetization Path

CI/CD content converts well because the reader is not only curious; they are trying to reduce production risk. Solo developers can start with ClaudeCodeLab products for reusable CLAUDE.md, review prompts, and CI checklists. Teams that need branch protection, GitHub Actions, secrets, approval policy, rollback, and Claude Code review around a real repository should use Claude Code training and consultation.

For the next internal steps, read advanced GitHub Actions with Claude Code, testing strategies, and security best practices. Together they cover the core loop: checks, evidence, permission boundaries, and release recovery.

Final Notes

The best first rollout is not full production automation. Start with the PR quality gate and read-only Claude Code review. In practice, that combination improves merge conversations quickly because failures are visible and review comments are tied to evidence. Add staging deployment next, then production approval and rollback after the team agrees on ownership.