Lesson 465 of 2116
Claude Code In CI And GitHub Actions
Claude Code can run inside GitHub Actions or any CI runner — for code review, automated fixes, or release scaffolding. The discipline is in the permission scoping, not the prompt.
Lesson map
What this lesson covers
Learning path
The main moves in order
- 1What CI use cases look like
- 2CI integration
- 3GitHub Actions
- 4automated code review
Concept cluster
Terms to connect while reading
Section 1
What CI use cases look like
Once Claude Code can run headlessly, you can wire it into pipelines. Three durable patterns: PR-time code review (it comments on the diff), nightly maintenance (it bumps deps, runs migrations, opens PRs), and fix-on-failure (when CI breaks, an agent attempts a repair and pushes a fix branch).
The minimal Action
A skeleton review Action. The exact CLI flags drift; pin the version and check the docs page on setup day.
name: Claude Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
permissions:
pull-requests: write
contents: read
steps:
- uses: actions/checkout@v4
- name: Run Claude Code review
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
npx -y @anthropic-ai/claude-code \
--headless \
--task 'Review the diff in this PR. Comment on issues using the GitHub API. Skip nits.'The permission scoping rules
- 1Use the smallest permissions that work — read-only for review, write only for fix-on-failure
- 2Never give CI an API key with billing rights you can't tolerate burning
- 3Set per-job spend caps if available; protect the budget from runaway loops
- 4Run on PRs from forks with extra restrictions — don't expose secrets to untrusted PRs
- 5Always require a human reviewer to merge — the agent comments, the human approves
Cost discipline
An agent in CI can run on every push, every PR update, every nightly trigger. Token costs add up fast. Cap aggressively: only review the diff, not the whole repo; only re-run when meaningful changes happen; throttle nightly tasks to once per night, not per branch.
Compare the options
| Use case | Permissions | Cost discipline |
|---|---|---|
| PR review | Read code, comment on PR | Diff-only context |
| Nightly dep bumps | Write code, open PR | Once per night |
| Fix-on-failure | Write code, push branch | Cap retries; per-job spend cap |
| Doc generation | Read code, open PR with docs | Trigger on releases only |
Apply: build one CI workflow
- 1Pick a low-stakes use case (review nits on PRs)
- 2Wire up a workflow with read-only permissions
- 3Run it for a week; observe the comments
- 4Tune the prompt to skip the noise you don't want
- 5Only graduate to write permissions after you trust the read-only behavior
Key terms in this lesson
The big idea: Claude Code in CI is powerful and dangerous in equal measure. Scope tight, cap spend, keep humans in the merge loop.
End-of-lesson quiz
Check what stuck
15 questions · Score saves to your progress.
Tutor
Curious about “Claude Code In CI And GitHub Actions”?
Ask anything about this lesson. I’ll answer using just what you’re reading — short, friendly, grounded.
Progress saved locally in this browser. Sign in to sync across devices.
Related lessons
Keep going
Creators · 9 min
AI Tools: Pick an Eval Platform You Will Actually Use
Eval platforms only help if your team runs them; pick one that fits your CI, your team size, and the scoring methods you actually need.
Creators · 45 min
Structured Outputs: Make the Model Return Data You Can Trust
For production apps, pretty prose is often the wrong output. Learn when to use structured outputs, function calling, and schema validation.
Creators · 9 min
Pro Search vs Default: When To Spend The Compute
Pro Search runs more queries, reads more pages, and routes to a stronger model. It is not always worth the wait — knowing when it is is the skill.