Claude Code Review: How to Review Pull Requests with Claude

Claude code review means one of three things: Anthropic's managed Code Review through the Claude GitHub App, the /code-review command inside Claude Code, or a GitHub Actions workflow wired to the API. All three read the diff and the repository, then post findings. None of them runs your tests. This guide covers setup, catches, misses, and cost.

This page is part of our AI testing guide. It takes the three paths in order, then covers what the review misses, what it costs at real volume, and where an executed test fits.

What "Claude code review" can mean

Three products answer to the same name. They differ in where they run, who can use them, and how they bill.

Managed Code Review. Anthropic runs this one on its own infrastructure. You install the Claude GitHub App, choose which repositories it can see, and reviews arrive as inline comments plus a check run named Claude Code Review. It is a research preview on Team and Enterprise subscriptions, and not available to organizations with Zero Data Retention enabled. When this guide says "managed review", this is what it means.

The /code-review command. This runs inside a Claude Code session in your terminal, reviewing the commits on your branch ahead of upstream plus anything uncommitted. Nothing reaches GitHub unless you pass --comment. Any Claude Code user can run it, on any plan, with no GitHub App involved.

Your own workflow. The Claude Code GitHub Action runs Claude on your CI runner, on the events you choose, with a prompt you control. Running /install-github-app from a session installs the shared GitHub App, saves the authentication secret, and opens a pull request containing the workflow files. Or skip the action and call the Messages API yourself.

One naming detail catches people out. /review is now an alias of /code-review. Before Claude Code v2.1.223 it was a separate command that ran a single-pass, read-only review of a GitHub pull request. If an old script treats the two as different, that is why.

How managed Claude Code Review works

A review starts when a pull request opens, on every push, or when somebody asks, depending on the repository setting. Several agents then analyze the diff and the surrounding code in parallel, each looking for a different class of problem. A verification step checks each candidate against what the code actually does, which is where false positives get dropped. What survives is deduplicated, ranked by severity, and posted on the lines where the problem is, with a summary in the review body.

Every finding carries one of three markers. Important means a bug to fix before merging. Nit means minor and non-blocking. Pre-existing means the bug is real but this pull request did not introduce it. Each has a collapsible reasoning section showing why Claude flagged it and how it verified the problem.

The check run always completes with a neutral conclusion. It never approves and never blocks, so branch protection keeps behaving the way it did before. If you want a gate anyway, the last line of the check run details is a machine-readable severity breakdown your own CI can parse with gh and jq. A non-zero count of Important findings is the number worth gating on.

Anthropic says a review completes in 20 minutes on average, with cost scaling by pull request size and complexity. That is the vendor's own figure, not an independent measurement.

The open-source plugin behind the local command is more specific: four agents in parallel, two on CLAUDE.md compliance, one on obvious bugs in the change, one reading git blame for context. Each issue is scored 0 to 100 for confidence and anything under 80 is dropped. Anthropic's design claims about its own plugin, not a measured accuracy rate.

Set up the Claude GitHub App

An Owner enables Code Review once for the organization and then picks repositories. You need the Owner or Primary Owner role in your Claude organization, plus permission to install GitHub Apps in your GitHub organization.

1. Start setup. Find the Code Review section in Claude Code admin settings and click Setup.

2. Install the Claude GitHub App. Pick the GitHub organization, choose which repositories the app can access, and approve the permissions: read on repository contents, write on pull requests and checks.

3. Select repositories. If one is missing from the list, the app was not given access to it at install time.

4. Set the trigger per repository. Once after PR creation runs when the pull request opens or is marked ready. After every push runs on each push and auto-resolves threads as you fix things. Manual runs nothing until somebody asks. Every push catches the most and costs the most.

5. Add a REVIEW.md. Optional, and the step that changes the output most. The next section covers it.

Three comment commands start reviews on demand, whatever the trigger is set to. @claude review runs a single review. @claude review always runs one and subscribes the pull request to reviews on later pushes. @claude review once behaves like the bare command. Before a July 2026 update the bare command did subscribe later pushes, so team docs written earlier are now wrong.

Four rules govern them. The comment has to be top-level, not inline on a diff line. The command has to sit at the start of it. You need write, maintain, or admin permission. The pull request has to be open. A fifth trap is harder to spot: if your organization membership is private, which is GitHub's default, GitHub does not identify you to Claude as a member, so nothing happens. Make the membership public, or get added to the repository as a collaborator.

Fork pull requests are never reviewed automatically, in any mode. Only a comment command starts one, and the write access has to be on the base repository, not the fork.

Review a pull request locally with /code-review

You do not need the GitHub App to get a Claude review. Open Claude Code in the repository, switch to the branch, and run the command.

/code-review
/code-review main...my-feature
/code-review --comment

With no target it reviews the commits on your branch ahead of upstream plus uncommitted changes, so there has to be work in the tree for it to say anything. Pass a target to review something else: a file path, a pull request number, a branch name, or a range. --fix applies the findings to your working tree. --comment posts them as inline pull request comments. The review runs as a background subagent with its own context window.

Effort matters. At low and medium it reports only the findings it is most confident in. From high through max it broadens coverage and may include ones it is less sure about. With no level typed it reuses the last one you used, even from an earlier session.

Local output beats posting before the pull request exists, on a branch where half the findings concern code you were about to delete, and on a team that has not agreed to a bot commenting on its work. One caveat: the local review follows CLAUDE.md, but not REVIEW.md.

Automate reviews with GitHub Actions or the API

There are two ways to run this yourself, and they are not the same amount of work.

The supported path is the Claude Code GitHub Action. It authenticates with either ANTHROPIC_API_KEY or a subscription token stored as CLAUDE_CODE_OAUTH_TOKEN, and it can respond to @claude mentions or run a fixed prompt on pull request events. For review, it installs the code-review plugin and invokes its skill. The workflow below is Anthropic's documented pattern, running when a pull request is opened, updated, reopened, or marked ready.

name: Code Review

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

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

Store the key as a repository secret and never commit it. Keep your unit, integration, API, UI, and security test jobs as separate required checks, because this workflow reviews code and does not replace any of them.

Two lines decide where the output goes. --comment posts the review on the pull request; without it the findings stay in the workflow run log. The claude_args line has to stay even though the skill's own frontmatter names the same tool, because the action only starts the MCP server that posts inline comments when --allowedTools names it.

Three behaviors will save you a support thread. Claude skips draft and closed pull requests, ones it judges trivial or automated, and ones it has already commented on. GitHub withholds secrets from fork-triggered runs on public repositories, so reviews only run on same-repository branches. And id-token: write is required for the action's default authentication, so do not trim it while tightening permissions.

The other path is calling the Messages API yourself: fetch the diff, build the prompt, parse the response, post the comments. It buys control over model choice, output shape, and which files leave your network, and costs you retry logic, rate-limit handling, and maintenance. Our guide to automated code review covers placing either one in a pipeline without slowing the merge queue.

Prompts and REVIEW.md rules that produce useful comments

The default review is decent. The difference between decent and useful is almost always the instructions, not the model.

Pavel Mihaylov's write-up illustrates the gap. He started where everyone starts: a plain Claude Code session told to review this PR. It produced feedback, but as one large blob posted on the pull request. He then built a reviewer skill with a tighter brief. Flag bugs, security problems, performance problems, breaking changes, and serious architectural violations. Never flag style, naming, formatting, or minor refactors. Read the callers and the tests first. Post short inline comments on the exact lines, shaped as a category, the problem, and the fix, so a SQL injection arrives as one clause naming the parameterized query as its remedy. An author can act on that without a reply thread.

On the managed service the same job belongs in REVIEW.md at the repository root. Two files feed the review and they are not interchangeable. CLAUDE.md is general project context, and new violations of it are reported as nits. REVIEW.md is review-only, reaches the agents that find and verify findings as well as the ones that rank them, and is read as plain text with no import syntax expanded. Rules land more reliably there than buried in a long CLAUDE.md.

Five headings do most of the work. A starting REVIEW.md:

Severity
  Important: data loss, auth bypass, or a broken contract. Nothing else.
  Nit: at most three per review.

Skip
  Generated code, lockfiles, vendored dependencies, anything CI enforces.

Repository checks
  A new API route needs an integration test in the same pull request.
  A new database query needs an index, or a comment saying why not.

Evidence
  Cite the file and line. Do not infer behavior from a name.

Re-review
  New Important findings only. No new nits after the first pass.

Redefining Important is the line that changes the most, because the default calibration targets production code. For the process across a whole team, see how to do code reviews using AI.

What Claude catches, and what it misses

Start with what it is aimed at. Anthropic lists logic errors, security vulnerabilities, broken edge cases, subtle regressions, and pre-existing bugs in code the pull request touches. Formatting preferences and missing test coverage are not in that list.

Its documentation examples show the flavor. A check run example lists an Important finding, that a token refresh races with logout and leaves stale sessions active, alongside a Nit that a parse function silently returns zero on malformed input. The plugin README shows a three-issue review: missing error handling on an OAuth callback, a memory leak because OAuth state is never cleaned up in a finally block, and a naming violation from a CLAUDE.md rule. These are documentation examples, not disclosed findings from real pull requests, but they show the shape of a good finding: a named mechanism attached to a specific line.

Now the misses, with each source labelled, because they come from three different places.

• Runtime-only failures. CodeAnt, a competing vendor, notes that the managed reviewer cannot execute code, so it reasons about source rather than verifying against a running system. Bugs that need real data and real state sit outside what that can prove.

• Missing test coverage. An Anthropic product fact: not reported by default. A pull request adding an endpoint and no test passes review silently unless you add the rule yourself.

• Architectural awareness. Cloudflare, reporting on its own review system, says reviewers see the diff and surrounding code but not why the system was designed this way, or whether the change moves it in the right direction.

• Downstream effects of a contract change. Also Cloudflare: a reviewer can flag that an API contract changed, but not verify that every consumer was updated.

• Timing-dependent concurrency bugs. Cloudflare again: a missing lock is visible in a diff, and the ways a system can deadlock are not.

• Very large diffs. Cloudflare's point here is cost, not blindness: a 500-file refactor fanned out across frontier models costs real money.

Read Cloudflare's numbers with the caveat attached. In 30 days it completed 131,246 review runs across 48,095 merge requests in 5,169 repositories, at $1.19 mean cost per run, a median of 3 minutes 39 seconds, and 1.2 findings per run. That system mixes Claude Opus 4.7, Claude Sonnet 4.6, GPT-5.4, GPT-5.3 Codex, and Kimi K2.5, so it measures a mixed-model in-house system, not Claude Code Review. Their own summary is the honest one: not a replacement for human review, not with today's models.

Claude Code Review compared with other AI reviewers

The comparison that matters is what each reviewer bills for, and whether anything it says was checked against a running system.

The execution column is unanimous: all of them read code, none of them run it. The Claude price is Anthropic's own figure. The rest were checked against each vendor's live pricing page in July 2026 for our best AI code review tools roundup, and CodeRabbit is broken down further in the CodeRabbit alternatives guide.

The billing unit changes the answer more than the feature list does. Per-review pricing tracks how many pull requests you open, per-seat pricing how many engineers you employ. A ten-person team shipping 400 pull requests a month and a fifty-person team shipping 200 land on different tools.

On quality, be careful what you believe. No source we could find publishes an independent same-pull-request comparison of these tools with a shared bug set, a false-positive count, recall, runtime, and cost side by side. Every ranking in circulation, vendor tables included, is a vendor's. Run your own: point two reviewers at your last twenty merged pull requests and count the findings you would have acted on.

Cost, models, and rate limits: a worked calculation

Anthropic says managed Code Review averages $15 to $25 per review, varying with pull request size, codebase complexity, and how much verification the findings need. It is billed separately through usage credits and does not count against the usage included in your plan. Do the arithmetic before you turn it on.

Take a team that opens 200 pull requests a month. Reviewed once each, that is $3,000 to $5,000 a month. Switch the trigger to every push and the multiplier is the number of pushes, so at three pushes per pull request the same team is looking at $9,000 to $15,000. That dropdown is the biggest cost decision in the product. Manual mode plus an @claude review habit lands far below both.

Building it yourself on the API bills tokens instead. List prices per million tokens are $10 input and $50 output for Claude Fable 5, $5 and $25 for Claude Opus 5, $2 and $10 for Claude Sonnet 5, and $1 and $5 for Claude Haiku 4.5. A review sends the diff plus a lot of surrounding context, so input dominates, and prompt caching across re-reviews of the same pull request is where the savings are.

Rate limits apply at the organization level as requests, input tokens, and output tokens per minute, refilled continuously from a token bucket rather than reset on a clock, so a burst can trip a limit you are under on average. Exceeding one returns HTTP 429 with a retry-after header, which you honor instead of retrying immediately.

Can the reviewer prove the bug?

Here is a small pull request. It changes one handler so the organization id comes from the request body instead of the session. The diff is six lines. Every existing test passes, because every existing test sends the id its own user owns.

Level one, the static review. A good reviewer reads that diff and says the right thing: this looks like an authorization problem, because a caller now controls the value that scopes the query. It cites the file and line and explains the path. What it cannot tell you is whether something further up the stack already catches this, or what the endpoint returns when someone tries. The comment is a well-argued hypothesis.

Level two, an executed check. An agent checks out the branch, waits for the preview deployment, and runs the API, UI, and security scenarios against it. One signs in as a user in organization A and requests billing scoped to organization B. The response should be 403. It is 200, and the body holds another organization's invoices. Now there is a recorded request, a recorded response, and a timestamp, and nobody has to argue about whether the finding is real.

Level three, deterministic replay. Save the exact input, the environment, the seeded data, and the assertion. After the patch lands, rerun the same case unchanged. It returns 403, and it runs on every future pull request. The regression suite grew by a case that came from a real failure rather than a guess, which is the argument behind AI regression testing.

The claim here is narrow. Running tests does not replace code review, and the best findings are often about maintainability, intent, and design that no test will produce. But a review comment is a hypothesis until something reproduces it, and resolving a thread is weaker closure than a replay that used to fail and now passes.

A review policy that holds up

• A human still approves. The check is neutral by design and never blocks. Leave the human approval requirement in branch protection where it was.

• Existing CI stays required. Unit, integration, API, UI, and security jobs remain required checks. An AI review adds to the gate, it does not replace it.

• Review once per pull request, or on request. Every-push review quietly triples the bill. Start at once and escalate specific ones with @claude review always.

• Keep REVIEW.md short. A long file dilutes the rules that matter. Severity, a nit cap, skip paths, and two or three repository checks is plenty.

• Replay every claimed runtime bug. If a finding says something breaks at runtime, reproduce it and keep the reproduction. Same instinct as shift-left testing: move the proof earlier, not just the opinion.

• Treat Claude-written code like anyone else's. Same review, same tests, same bar. A second model or an executed test is the independent check, not a rule about who typed it.

How Qodex fits

Qodex reviews the pull request and can also run it. Six passes go over each change: more than a dozen static analyzers, a full read of every changed file, a blast-radius pass over the code graph, two frontier models, and live probes against the preview deployment. The same agent runs your API, UI, and security scenarios against that preview and attaches the evidence, whether that is the failing request, the response, or a screenshot. A Check Run posts with the review and blocks the merge if you told it to, configured per repository in .qodex.yaml. Replays are generated code with no model call, so the suite grows without the bill growing. More in our AI QA guide.

See how Qodex reviews pull requests

Frequently Asked Questions

Is Claude Code good at code review?

It is good at logic errors, security problems, and broken edge cases in the diff and the code around it. Anthropic's documented examples are the strongest public evidence, and no independent benchmark exists. It does not run code, so a bug that only appears at runtime needs a test.

How do I use Claude Code to review a pull request?

Two ways. Run /code-review in a Claude Code session inside the repository, adding --comment if you want the findings posted. Or install the Claude GitHub App, set the repository trigger, and comment @claude review at the top level of any open pull request.

Are /review and /code-review the same command?

Today, yes. /review is now an alias of /code-review. Before Claude Code v2.1.223 they were different commands: /review ran a single-pass, read-only review of a GitHub pull request. Scripts and team docs written before that change may still treat the two as separate.

How much does Claude Code Review cost per pull request?

Anthropic says $15 to $25 per review on average, varying with pull request size, codebase complexity, and how much verification the findings need. It is billed separately as usage credits. Reviewing on every push multiplies that by the number of pushes.

Which Claude plans include managed Code Review?

Team and Enterprise subscriptions, as a research preview. It is not available to organizations with Zero Data Retention enabled. On any other plan you can still review a diff locally with /code-review, which needs no GitHub App and no admin setup.

Can Claude Code Review run my tests?

No. It reads the diff and the surrounding repository and reasons about them. It does not execute your code and does not report missing test coverage by default. Keep test jobs as required checks, or add an agent that runs scenarios against the preview deployment.

Can Claude review code that Claude wrote?

Yes, and it does find real problems. The catch is that the same model family carries the same blind spots into both jobs, so a mistake it was prone to making is one it is prone to missing. A second model, or a test that runs, is the independent check.

How does Claude Code Review compare with CodeRabbit, Qodo, CodeAnt, and Greptile?

They differ most in billing unit and platform support: per review, per seat, or per developer, and GitHub only versus several Git hosts. No independent same-pull-request benchmark exists, so treat every ranking as a vendor's. Our best AI code review tools roundup has prices verified in July 2026.