Claude Code · Lesson 22

Code Review

Claude Code can automatically review every GitHub pull request your team opens — posting inline comments on the exact lines where problems live, tagged by severity, without blocking your existing merge workflows.

GitHub PRsInline CommentsMulti-AgentSeverity TagsResearch Preview
ℹ️ Info:Code Review is in research preview. It requires a Team or Enterprise subscription and is not available for organisations with Zero Data Retention enabled.

How It Works

When a pull request opens (or a push lands, depending on your settings), a fleet of specialised agents analyses the diff in the context of your full codebase — not just the changed lines. Each agent looks for a different class of problem: logic errors, security gaps, broken edge cases, subtle regressions. A verification step then cross-checks each candidate finding against the actual code to filter out false positives before anything is posted.

The results land as inline PR comments on the exact diff lines where the issue was found, plus a summary in the review body. If no issues are found, Claude leaves a brief confirmation comment instead of staying silent.

PR opened / pushed
⚙️
Parallel agents analyse diff + codebase
Verification step filters false positives
💬
Inline comments posted by severity
Tip:Reviews complete in 20 minutes on average. They never approve or reject a PR — findings are informational, so your existing branch protection rules are unaffected.

Severity Levels

Every finding is tagged with one of three severity levels so you can triage quickly.

🔴
Important
A real bug that should be fixed before merging. Claude verified it against the actual code — not an inference from naming or style.
🟡
Nit
A minor issue worth cleaning up, but not blocking. Dead code, an unused parameter, an edge case with low impact.
🟣
Pre-existing
A bug that exists in the codebase but was not introduced by this PR. Surfaced so the team is aware, without blocking the current change.

Each inline comment also includes a collapsible Extended reasoning section. Expand it to see exactly how Claude verified the issue — which file and line it traced, what code path it followed.

What It Looks Like on a Real PR

Below is an example review on a pull request that adds payment retry logic. Claude found one Important bug (potential double-charge on network timeout) and one Nit (unused parameter).

Open
Add payment retry logic to checkout service#247 · priya wants to merge 8 commits into main
Checks
Claude Code Review— 2 findingsDetails
src/checkout/retry.ts:58- await retryPayment(orderId, attempts)
+58+ await retryPayment(orderId, attempts, { maxRetries: 3 })
claude-code-review🔴 Important2 minutes ago

Retry loop may charge a customer multiple times. If the first payment attempt succeeds but the network times out before the response arrives, retryPayment will re-submit the same charge. Consider checking for an existing successful transaction with this orderId before each attempt.

Extended reasoning ▸
Verified at src/payments/gateway.ts:34: the gateway does not use an idempotency key by default. Re-submission on timeout will create a new charge record, confirmed by reviewing the Stripe API call on line 67.
👍 0👎 0
claude-code-review🟡 Nit
attempts is passed to retryPayment but never used inside the function (see retry.ts:12). Either wire it up or remove the parameter to avoid confusion.
Tip:Click 👍 on comments that are useful and 👎 on ones that are wrong or noisy. Anthropic uses these reactions to tune the reviewer after the PR merges.

Set Up Code Review

An admin enables Code Review once for the whole organisation, then picks which repositories to include and how each one triggers.

1
Open Claude Code admin settings

Go to claude.ai/admin-settings/claude-code and scroll to the Code Review section. You need admin access to your Claude organisation and permission to install GitHub Apps.

2
Install the Claude GitHub App

Click Setup to start the GitHub App installation flow. Grant the app these repository permissions:

Contents: ReadIssues: Read & writePull requests: Read & write
3
Select repositories and set trigger mode

Choose which repositories to enable. For each one, pick a Review Behavior from the dropdown:

Once after PR creation
One review per PR when it opens or is marked ready for review.
Lowest
After every push
Re-reviews on every push, catching new issues and auto-resolving fixed threads.
Highest
Manual
Reviews only when someone comments @claude review on the PR.
Pay as you go
Code ReviewResearch Preview
RepositoryReview BehaviorStatus
acme/api-serviceAfter every pushEnabled
acme/frontendOnce after PR creationEnabled
acme/infraManualDisabled

Trigger a Review by Comment

Two comment commands let anyone request a review on demand, regardless of the repository's configured trigger. Post them as top-level PR comments — not as replies to inline diff threads.

@claude review
Review + subscribe
Starts a review immediately and subscribes this PR to future push-triggered reviews. Use this when you want ongoing review coverage.
@claude review once
One-off review
Starts a single review without changing the PR's trigger behaviour. Use for a second opinion or to re-review after a major rebase.
ℹ️ Info:If a review is already running on the PR, the manual request is queued and starts as soon as the in-progress review finishes. Draft PRs are also reviewed when you use a manual trigger — the explicit request overrides the draft restriction.

Customise with REVIEW.md

Add a REVIEW.md file to your repository root to tune how Code Review behaves on that repo. Its contents are injected as the highest-priority instruction for every agent in the review pipeline — overriding the default guidance.

🎯
Redefine severity
Change what "Important" means for your repo. A docs repo might only flag broken links; a payment service might escalate any PII leak.
🔇
Cap nit volume
Limit how many 🟡 Nit comments appear per review so the author isn't overwhelmed by style suggestions.
⏭️
Skip paths
Tell Claude to ignore generated files, lockfiles, migration scripts, or any path your CI already covers.
Always-check rules
Add repo-specific checks that apply to every PR, like "new API routes must have an integration test".

Here is an original example for a backend API service:

# REVIEW.md — Backend API Service

## What counts as Important here
Only flag findings that would break production behaviour, expose PII, or block
a rollback: incorrect logic, unscoped DB queries, passwords or user IDs in logs,
and migrations that are not backward-compatible.
Style and naming suggestions are Nit at most.

## Cap the nits
Report at most four Nit comments per review. If you found more, summarise the
extras as "plus N similar items" in the review body. If every finding is a Nit,
open the summary with "No blocking issues found."

## Skip these paths
- src/generated/           (auto-generated from schema)
- **/*.lock                (dependency lockfiles)
- migrations/              (reviewed separately by the DBA team)
- Anything that only changes comments or whitespace

## Always check
- New /api routes have an integration test in tests/integration/
- Log statements do not include req.body, user.email, or user.id
- Database queries filter by tenant_id when tenant data is involved
Tip:Keep REVIEW.md short and focused. A long file dilutes the rules that matter most. Use CLAUDE.md for general project context and reserve REVIEW.md for instructions that specifically change review behaviour.

Pricing

Code Review is billed by token usage, separately from your plan's included usage. Cost scales with PR size and codebase complexity. Check the admin usage page for current pricing in your organisation.

Once after PR
One review per PR
Runs once when the PR is opened
After every push
Runs on each push
Cost increases with each new push
Manual only
On-demand via @claude
You control exactly when it runs
ℹ️ Info:Set a monthly spend cap at claude.ai/admin-settings/usage to avoid unexpected charges. You can also monitor weekly spend in the analytics dashboard.

Troubleshooting

⚠️No check run appeared after the PR opened
  1. Confirm the repository is listed in admin settings and Code Review is enabled.
  2. Confirm the Claude GitHub App has access to that repository.
  3. If Review Behavior is Manual, comment @claude review on the PR to start.
  4. To verify setup quickly, open a test PR and watch the Checks tab.
⚠️Review failed or timed out — no findings posted
  1. Comment @claude review once to start a fresh one-off review without subscribing to future pushes.
  2. Do not use the GitHub Re-run button — it does not retrigger Code Review.
  3. If the PR is already subscribed, pushing a new commit also starts a new review.
⚠️Review ran but I can't find the inline comments
  1. Click Details next to the Claude Code Review check — the severity table lists every finding even if inline comments were rejected by GitHub.
  2. Open the Files changed tab to see findings as diff annotations.
  3. If you pushed while a review was running, comments on moved lines appear under Additional findings in the review body.
⚠️Review was skipped with a spend-cap message
  1. Your organisation has hit its monthly Code Review spend cap.
  2. Reviews resume automatically at the start of the next billing period.
  3. An admin can raise the cap immediately at claude.ai/admin-settings/usage.

Quick Reference

TaskHow
Enable for your organisationclaude.ai/admin-settings/claude-code → Code Review → Setup
Trigger a review manually@claude review (top-level PR comment)
Get a one-off review@claude review once
Retrigger a failed review@claude review once or push a new commit
Customise what gets flaggedAdd REVIEW.md to your repository root
Set a monthly spend capclaude.ai/admin-settings/usage
View per-repo costsclaude.ai/analytics/code-review
See findings when comments are missingChecks tab → Details link or Files changed annotations

What's Next

Code review is part of your workflow. Next: techniques for getting consistently better results from Claude Code on any task.