Anthropic shipped /code-review as a built-in Claude Code command in the week of May 18-22, 2026, alongside auto mode on the Pro plan and the per-category /usage breakdown (release notes). The Claude Code code review command does one job: it reads the diff you are about to merge and tells you what is broken in it. You run it inside a Claude Code session, it reports correctness bugs, and if you ask, it posts those bugs as inline comments on your pull request or applies the fixes straight to your working tree.
This is a first-party command, not a marketplace plugin and not one of the "AI code review" SaaS products that rank for the same search. Those are separate companies wrapping a model around your GitHub webhook. /code-review ships with the CLI, so if you have a recent Claude Code build, you already have it.
What /code-review actually does
The command reviews the current diff for correctness bugs: logic that produces wrong results, syntax and type errors, missing imports, unresolved references, the kind of thing that breaks at runtime rather than the kind that annoys a linter. From v2.1.151 it also reports reuse, simplification, and efficiency cleanups in the same pass, so you get the bug-hunting and the tidy-up suggestions together. Formatting preferences and missing test coverage are not the target. What it cares about is correctness.
By default it looks at your current diff, meaning the uncommitted and recently committed changes on your branch. Pass a path or a PR reference and it reviews that instead. So /code-review checks what you are working on right now, while /code-review 1234 points it at PR #1234.
The behavior scales with an effort argument. Lower effort levels return fewer, higher-confidence findings. Run it at high through max and you get broader coverage that may include uncertain findings, the kind worth a second look but not a guaranteed bug. With no effort argument the review just uses your session's current effort level. The pattern is what you would expect: a fast skim before a small commit, a thorough sweep before an auth refactor.
One sentence in the docs is the whole reason this command exists. /code-review ultra runs the deeper ultrareview in the cloud rather than reviewing locally in your session.
The /ultrareview lineage
/code-review did not appear from nothing. It grew out of /ultrareview, which opened as a research preview back in the week of April 20-24, 2026 (release notes). Ultrareview runs a fleet of bug-hunting agents in the cloud against your branch or a PR, and the findings land back in the CLI or Desktop automatically. Anthropic's own framing was blunt: run it before merging critical changes such as auth or data migrations.
The mechanism is worth understanding, because it explains why this catches things a single-pass review misses. Multiple agents analyze the diff and the surrounding code in parallel on Anthropic infrastructure, and each agent hunts for a different class of issue. A verification step then checks each candidate finding against how the code actually behaves, which filters out false positives before they reach you (Code Review docs). A naive model pass hands you ten plausible-sounding warnings and leaves you to sort the real ones from the hallucinated ones. The verification step is the part that makes the output worth reading.
When you type /code-review ultra, you are dispatching that cloud fleet from your terminal. The local /code-review is the quick version, and ultra is what you reach for on the change you cannot afford to get wrong.
Where the findings show up
There are two destinations, and you pick.
By default, findings print in your session. You read them, you act on them, and nothing leaves your machine. That is the local loop: you review the diff before you even push.
Pass --comment and the findings post as inline comments on the GitHub PR, attached to the specific lines where each issue lives. Pass --fix and the command applies the findings to your working tree after the review, so the bugs it found get patched in place instead of just described. You can stack the cloud and the fix together: /code-review ultra --fix runs the deeper ultrareview in the cloud, then applies its findings to your working tree once they arrive back in your session. Dispatch a fleet of agents, step away for a few minutes, and come back to a patched branch.
A naming note that will save you a confused half hour. The command was called /simplify before v2.1.147, back when it applied fixes by default. From v2.1.154, /simplify is a separate cleanup-only review that tidies code without hunting for bugs. If you scripted /simplify expecting it to find bugs, switch to /code-review --fix. The bug-finding behavior moved, and the cleanup-only behavior kept the old name.
The managed service is a different surface
There is a second thing called Code Review, and it is easy to conflate with the command. The managed service watches your GitHub PRs through a GitHub App and reviews them automatically on open, on push, or when someone comments @claude review. It is in research preview, available on Team and Enterprise plans, and not available for organizations with Zero Data Retention enabled (docs).
The managed service tags every finding with a severity marker: 🔴 Important for a bug to fix before merging, 🟡 Nit for a minor issue, 🟣 Pre-existing for a bug that was already in the codebase and not introduced by this PR. It posts a Claude Code Review check run that always completes with a neutral conclusion, so it never blocks a merge through branch protection. Reviews complete in about 20 minutes on average and cost roughly $15-25 per review depending on PR size, billed through usage credits separately from your plan's included usage. You tune what it flags with a CLAUDE.md or a review-only REVIEW.md at your repo root.
The line that matters for choosing is this: the local /code-review command needs no GitHub App. Run it in any Claude Code session and it reviews a diff in your terminal. The GitHub App is only for the automatic, every-PR, posts-comments-without-you-asking version. One is a thing you invoke; the other is a thing your org installs once and then forgets is running.
What it catches, and what it does not
Inside the diff, expect it to flag the bugs that survive a human skim because they hide in the gap between two files. A token refresh that races with logout. A parser that silently returns zero on malformed input. An unscoped database query that leaks across tenants. A migration that is not backward compatible. Because of the verification step, a posted finding usually comes with a file:line citation and an expandable explanation of why it is a bug and how the agent confirmed it, rather than a vague hunch.
What it will not do is replace the human who knows why the feature exists. It does not know that the "wrong" behavior you wrote is a deliberate workaround for a vendor bug, unless you told it so in REVIEW.md. It does not weigh whether the feature should ship at all. And it does not catch the bug that lives in code the diff never touches and the agents never read. So calibrate accordingly. It is a fast, tireless reviewer for the mechanical correctness of a change. Run it before the human review to clear the obvious stuff, and let the human spend their attention on judgment.
Against a SaaS reviewer, the differences are concrete. /code-review runs from your terminal against an uncommitted diff before a PR even exists, which no webhook-based product can do. It uses the same effort and model controls as the rest of your Claude Code session. And the cloud ultra path runs on Anthropic's own multi-agent verification pipeline rather than a single model call wrapped in a third-party prompt. The trade-off is that the managed every-PR automation is Team and Enterprise only, whereas the SaaS tools will happily bill a solo developer.
If the bug you keep shipping is the same review nitpick on every PR, that is a workflow you can capture once. Tools like Knack turn a short interview into a SKILL.md that encodes your review rules so Claude applies them the same way every time, in Claude Code or Codex or Cursor. Past that, the honest workflow is small. Type /code-review before you push. Type /code-review ultra before you touch auth. Read the findings, fix the real ones, and merge.
Sources cited: