Claude Code code review: which command to run, and what a review finds

The five routes to a review

Anthropic's own comparison of the options is the shortest way into this. The five rows below are that table, with the plan requirement that decides who can use each one.

All five read a diff and report on it. None of them replaces a reader who knows why the change was made, which is worth holding on to before the pricing and the flags below make one of them look like a substitute for review.

Why /review and /code-review confuse people

In the documentation as it stands, /review is an alias of /code-review. They are one command. Most of the confusion comes from the versions before that, and from what the two names meant then.

Before Claude Code v2.1.223, /review was a separate command that ran a single-pass, read-only review of a GitHub pull request by number, and it listed your open pull requests to pick from when you ran it with no argument. From v2.1.186 through v2.1.201, it ran the same multi-agent engine as /code-review medium. So an older tutorial, or a comment written a few months back, can describe a behaviour the current command does not have.

A skill named code-review

There is a second, quieter way the two names drift apart on one machine. A project or personal skill named code-review runs in place of the bundled one, and Anthropic says the bundled alias /review keeps running the bundled review, not your skill. If a teammate's /review behaves differently from yours, that is one place to look.

The bundled review has no file to open. Anthropic describes /code-review as a bundled skill, which means its instructions are built into Claude Code and there is no SKILL.md on disk to read or edit. To give it project rules, you put them in CLAUDE.md, or you replace it with a skill of your own.

Anthropic's command reference does not mention installing a plugin to use the local review command. The plugin name comes from Anthropic's GitHub Actions page instead: code-review@claude-code-plugins, which is what the action installs to run its review in CI.

What /code-review does in a session

Run it with no target and it reviews the commits on your branch ahead of its upstream branch, plus your uncommitted changes. If the branch has no upstream, it compares against main, or against the previous commit.

To review something else, everything left on the line after the flags is read as the target. That can be a pull request number, a branch name, a file or directory path, or a revision range.

It runs beside your conversation, not inside it

The review runs as a background subagent with its own context window, so it does not fill your conversation, and the findings arrive when it finishes. An effort level decides how far it looks: at low it reports the findings it is most confident in, and from medium through max it widens coverage. With no level typed, it reuses the last level you typed in this or an earlier session, and if you have never typed one it uses the session's own effort.

The flags that change what it does

--fix asks Claude to apply the findings to your working tree after the review, and those edits go through your permission mode. --comment posts the findings on a GitHub pull request as inline comments, or on a GitLab merge request as a single note. --max-findings caps the list, or takes all to remove the cap.

Two limits are worth knowing before you rely on --fix. A background review applies its fixes outside your session's checkpoints, so a /rewind afterwards restores only the files Claude had already edited in the conversation and the review's edits to other files stay, which means git is the way to undo them. Run the review in the foreground, with -p or by setting CLAUDE_CODE_DISABLE_BACKGROUND_TASKS to 1, and its edits land inside your own turn where rewind does restore them.

It follows your CLAUDE.md files, including in a non-interactive run, and it does not read REVIEW.md. Claude can also start the review itself when you ask for one in plain language, or from a session-scoped scheduled task. To stop that while keeping the command available to you, Anthropic documents a skillOverrides entry of "code-review": "user-invocable-only" in a settings file.

What a review finds, and what it misses

Anthropic's managed service focuses on correctness by default: bugs that would break production rather than formatting preferences or missing test coverage. The local command looks for correctness bugs too, and depending on your model and effort level it also reports cleanup opportunities.

What it reads is narrower than what you might assume. Anthropic says a managed review works from reading the diff and the surrounding code, without building or running your code. Anything that only shows up when the program runs is outside what that read can see.

Anthropic says this about its own reviews: Code Review uses AI to review code and may miss bugs, security vulnerabilities or other issues, and a review with no findings does not mean your code is error-free or secure. Read a clean review as a review that found nothing, never as proof that nothing is there.

Two neighbours that are not the same job

/security-review looks only for security problems in the changes on your branch, reviewing the diff between your branch and origin's default branch, and it needs an origin remote to have something to compare against. /simplify goes the other way: four review agents run in parallel over reuse, simplification, efficiency and whether the change sits at the right level, and Anthropic says that review does not look for correctness bugs at all. Neither one is a substitute for /code-review.

How the managed service labels what it finds

Code Review posts each finding as an inline comment marked with one of three severities. Red is Important, a bug that should be fixed before merging. Yellow is a Nit, worth fixing but not blocking. Purple is Pre-existing, a bug that was already in the codebase and was not introduced by this pull request. Where the review recorded its reasoning, the comment carries a collapsed Why this was flagged section explaining how the problem was verified.

The deeper review in the cloud

Adding ultra sends the review to a cloud sandbox instead. Anthropic describes it as a fleet of reviewer agents that work the change in parallel, with every reported finding independently reproduced and verified, which is what separates it from the local command: fewer style suggestions, more bugs, wider coverage, and no load on your machine while it runs.

Its scope is your current branch against the repository's default branch, plus uncommitted and staged changes. You can pass a branch name, a commit id or a tag as a different base, and a pull request number to review a PR instead. PR mode needs the repository to be on github.com; on a GitHub Enterprise Server instance, Anthropic's guidance is to run the command without a PR number and review your local branch. Before it launches, Claude Code shows a confirmation dialog with the review's scope, your remaining free runs and the estimated cost, and for a branch review that scope includes the file and line count.

Pro and Max accounts get three free runs, as a one-time allotment per account that does not refresh. After those, Anthropic says a review typically costs between 5 and 25 US dollars in usage credits depending on the size of the change, and that a review takes roughly 15 to 25 minutes. A run counts once the review starts in the sandbox, so a review you stop early still uses a free run, while a paid review bills only for the portion that ran.

Ultrareview is not available everywhere. It needs a claude.ai account sign-in, and Anthropic lists it as unavailable on Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry, and to organizations with Zero Data Retention or the HIPAA configuration applied; in those cases /code-review ultra runs a local review in your session instead of failing. Organizations that use customer-managed encryption keys are the separate case: Anthropic says they cannot run ultrareview at all, and the documented step is to run /code-review locally.

Reviewing every pull request

Code Review is the managed service, and it is the one Anthropic runs for you: a review starts from pull request activity, with no workflow file of yours to keep and no command to type. Anthropic lists it for Team and Enterprise organizations with repositories on GitHub, including GitHub Enterprise Server, after an Owner turns it on and installs the Claude GitHub App.

A review runs in four stages. Several agents examine the diff and the surrounding code in parallel. A verification step checks the candidate findings against the code and drops the false positives. What remains is deduplicated and ranked by severity. Then the review posts its results on the pull request.

What it leaves behind is a set of inline comments with a summary in the review body, a check run named Claude Code Review whose details hold every finding in one table, and, when it finds nothing, a note where the findings would have been. Anthropic is direct about the limits of that check run: it concludes as neutral, or as skipped when an earlier result was kept, and never as a failure, so a finished review will not fail a required check. A review never approves or blocks a pull request either, and the decision to merge stays with your team.

How often a review runs is a per-repository setting. A repository starts at after every push, which runs the most reviews and costs the most, and it can be set to once after the pull request is created, or to manual. Anyone with write access can comment @claude review to start a single review, @claude review always to subscribe the pull request to push-triggered reviews as well, and @claude review stop to end that subscription. Drafts and pull requests from forks are skipped by automatic reviews.

Two files change what gets flagged. CLAUDE.md is read as project context, so a change that breaks one of its rules becomes a finding. REVIEW.md is for review rules alone: what you want flagged, at what severity, and which paths to skip. Both can sit at the repository root, and a REVIEW.md in a subdirectory adds checks for changes under that path. Anthropic reads REVIEW.md from the base or default branch and never from the pull request's own changes, which is the detail that stops a contribution from rewriting the rules it is reviewed against.

The service has no flat price per review. Anthropic bills it on token usage through usage credits, separately from your plan's included usage, to the organization rather than to the developer who opened the pull request. An organization can set a monthly spend limit for Code Review, and reviews are skipped, with a comment on the pull request naming the cause, once that limit, the organization's overall monthly spend limit or its credit balance runs low.

The review inside your own CI

The fourth route keeps everything on your own runners. The Claude Code GitHub Action can install the code-review plugin and run its skill on the pull request events you choose, and Anthropic's documented example does that on opened, synchronize, ready for review and reopened.

plugin_marketplaces is the marketplace the action installs the plugin from, so leave it out and there is nothing to install from. Anthropic then names two things as the pair that controls where the review goes: --comment, in the prompt, and the claude_args line, because the action starts the MCP server that posts inline comments only when --allowedTools in claude_args names the tool.

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"'

--comment is what puts the review on the pull request, as an inline comment per issue or one summary comment when it finds none. Without it the findings stay in the workflow run log. The example workflow skips draft and closed pull requests, pull requests it judges not to need a review, and pull requests that already carry a comment from Claude.

One limit is structural rather than a setting. On a public repository, GitHub withholds secrets from runs triggered by a fork's pull request, so a review workflow there only runs on pull requests from branches in the same repository. Claude Code also runs in CI on GitLab, if that is where your merge requests live.

The fifth route is the one you write. A reviewer is an ordinary subagent or skill, invoked by you or by Claude during a session, so it follows whatever rules you put in it. Our guide to Claude Code subagents covers how a subagent is defined and how to give it a review brief of its own.

What each route costs

The five routes are billed in three different ways, and only one of them shows you a price before it runs.

If the bill is the part you came for, the Claude Code cost calculator works through what Claude Code costs per session and per plan.

Where a desktop app puts the review

Omniscio is the desktop app we make for running Claude Code sessions. Its dev pipeline has an AI Code Review phase you can switch on after any phase of a run, and it is the piece of the app that answers the question this page is about.

It is off everywhere by default, and you place it yourself: one switch per point, after Plan, Red Team, Build, Elegance or Docs, so a review can sit where it is worth paying for instead of after every step. At each point you enable, the run gets fresh-context reviewers that see only the work and a fixed review brief, never the orchestrating session's reasoning. How many is a setting you control.

What the pipeline adds is the loop around the review. Reviewers are read-only and return findings ranked Blocker, Major or Minor, and the run verifies each one, discards the false positives, fixes the real ones and re-verifies before it moves on. A review that comes back clean, or whose findings the run already fixed, closes green and the run continues with nothing in your inbox. A review that turns up something you should weigh in on stops the run and waits for you.

While a review is out, the session stays out of your inbox under an Auto-waited tag instead of landing there as something that needs you, and the results wake it when they arrive. The wait is capped at four hours as a safety net. A run also cannot finish over a review that is still out: while the review is owed, the next phase's check-in is refused and the change cannot be marked ready to merge.

The reviewers are in-session subagents by default, and a review switched on that way never starts paid sessions at another vendor on its own. Name another company in that phase's reviewer setting and it does start real sessions there: naming one is the authorization, it spends money at that company's rates on every run, and the work under review leaves your machine for theirs.

What you get afterwards is a record. The AI code review card keeps a scorecard per model with reviews, no-answers, serious findings, minor findings, false alarms, how often its reviews were approved, total cost and cost per review, and below it the same count for whose work was reviewed. Only counts and names are stored, never code or the findings themselves, and the results are kept for a year. One switch at the top of the card turns every review step off at once, including in runs already under way.

The dev pipeline page in our documentation covers the phases and the gates, and the agent crews page covers what a mission looks like when several sessions run together. The features page lists the rest of the app and the download page has the installers. If you want to write a reviewer of your own instead, our guide to Claude Code subagents covers the subagent half of that, and the orchestration guide covers where a review sits among the other jobs a run does.

Sources

Every Anthropic fact on this page rests on one of these, and the date beside each one is the day we read it. The Omniscio section rests on our own documentation and the defaults in the app, and the rows in the fact ledger beside this page name the file for each claim.

• Review locally with /code-review, for the local command, its targets, flags, effort levels, background subagent, the checkpoint limit on --fix, and what it reads. Read October 25, 2026.
• Code Review, for the managed service, its plans and hosts, the four stages, the check run, the review levels, and Anthropic's own note on what a review can miss. Read October 25, 2026.
• Read and request reviews on a pull request, for the three severity markers, the comment commands and the severity line a team can gate on. Read October 25, 2026.
• Customize Code Review, for CLAUDE.md and REVIEW.md, the subdirectory form, and which branch REVIEW.md is read from. Read October 25, 2026.
• Code Review costs and usage, for usage-credit billing, the monthly spend limit and the skipped-review behaviour at the limit. Read October 25, 2026.
• Find bugs with ultrareview, for the cloud review, its scope, the confirmation dialog, the free runs and the 5 to 25 dollar range. Read October 25, 2026.
• Commands, for /code-review, the /review alias and its history before v2.1.223, /security-review and /simplify. Read October 25, 2026.
• Skills, for what a bundled skill is, how a skill named code-review replaces the bundled one, and the alias behaviour. Read October 25, 2026.
• Claude Code GitHub Actions, for the review workflow, the plugin it installs, and the fork limitation on public repositories. Read October 25, 2026.

Anthropic moves both the commands and the wording. The pages above carry version notes such as "Before v2.1.223" and "Requires Claude Code v2.1.257 or later", and the pricing on the ultrareview page is labelled a research preview whose terms may change. Read the source again before you trust a copy of this page from a few months back.

Common questions

What is the difference between /review and /code-review?

Nothing, in the current documentation: /review is listed as an alias of /code-review and runs the same bundled skill. Before Claude Code v2.1.223 the two were separate, when /review ran a single-pass, read-only review of a GitHub pull request by number.

Does /code-review work on any Claude plan?

Yes. Anthropic says the command works on any plan, and because it runs inside your own session it counts toward your plan's usage or your API billing the same way the rest of the session does.

What does /code-review ultra cost?

Pro and Max accounts get three free ultrareview runs, as a one-time allotment that does not refresh. After those, Anthropic says a review typically costs 5 to 25 US dollars in usage credits depending on the size of the change, and takes roughly 15 to 25 minutes.

Can /code-review put its findings on the pull request?

Yes. The --comment flag posts the findings on a GitHub pull request as inline comments, or on a GitLab merge request as a single note, which needs Claude Code v2.1.257 or later. Without the flag the findings appear in your conversation and nothing is posted.

Do I need a Team or Enterprise plan for Code Review?

For the managed service that reviews every pull request on GitHub, Anthropic lists Team and Enterprise plans, with repositories hosted on GitHub, and an Owner of the organization turns it on. The /code-review command in a session is a different tool and works on any plan.

Can a Claude code review block a merge?

The managed Code Review service does not: Anthropic says a review never approves or blocks a pull request, and its check run never concludes as a failure. A team that wants a gate reads the severity counts from the check run's details and fails its own job on them.

Does /code-review read REVIEW.md?

No. Anthropic says the command reads your CLAUDE.md files and not REVIEW.md, which configures the managed Code Review service on GitHub pull requests. Guidance you want applied in both places belongs in CLAUDE.md.

What does a Claude code review miss?

Anthropic states that its reviews may miss bugs, security vulnerabilities and other issues, and that a review with no findings does not mean the code is error-free or secure. The managed service works from the diff and the surrounding code without building or running it, so anything that only fails at runtime is outside what it can see.