Claude Code Code Review: The Managed Service And The Local Command

If you search for Claude code review you will find two different things, and the fastest way to waste an hour is to read the documentation for one while trying to use the other. The managed Claude Code Review service runs on GitHub and comments on pull requests. The /code-review command runs inside the desktop app and reviews the changes sitting in front of you right now.

The rest of this post covers both, starting with the managed one, because that is the one people are usually trying to evaluate.

It reads the pull request and leaves inline comments on the specific lines it has a problem with. Each comment carries a severity marker, and there are three of them.

That third category is more useful than it sounds. Most review tools either stay silent about surrounding code or bury you in unrelated complaints. Labelling them separately means you can see them without feeling obliged to fix them in this pull request.

The check the service posts is always neutral. It never fails. That means a Claude review cannot block a merge no matter how many Important comments it leaves.

I have watched teams treat this as a missing feature and go looking for a way to make it gate merges. I would push back on that instinct. An automated reviewer that can block your pipeline becomes something people learn to route around, and the workarounds are always worse than the original problem. A reviewer that advises but never blocks stays useful because nobody is fighting it.

There are three trigger modes, and the right one depends mostly on how noisy your pull requests are.

You can also drive it from a comment. Writing @claude review triggers a single review, @claude review once sets a one-time review for that pull request, and @claude review always switches it to reviewing every push.

For most teams I would start on manual, move to once after creation when people stop finding the output surprising, and only go to every push on branches where the churn is genuinely meaningful. Every push is the setting that turns a helpful reviewer into background noise.

Two files change what the reviewer says, and they carry different weight.

Your CLAUDE.md is read as a source of conventions. When code violates something in it, the reviewer raises that as a nit. This is a good reason to keep the conventions in that file honest, because vague rules produce vague nits and everyone starts ignoring them.

REVIEW.md is the stronger lever. Instructions in it are injected at the highest priority, which makes it the right place for the things you actually care about. If your team has a rule that database migrations must always be reversible, or that nothing new is allowed to reach a particular module, that belongs in REVIEW.md rather than buried in general project context.

The documented average is roughly fifteen to twenty five dollars per review, billed through usage credits. That is a real number and it is worth sitting with, because it changes which trigger mode makes sense.

At that rate, review on every push across a busy repository is a meaningful line item rather than a rounding error. Review once on creation, for pull requests that matter, is a much easier thing to justify. The cost profile is the strongest argument for being conservative with the trigger setting.

If you are not on a plan with the managed service, or you simply want a review before anyone else sees the code, the desktop app has /code-review, also available as /review.

It runs as a background subagent, so your session stays usable while it works. Two flags matter. Passing --fix lets it apply changes rather than just describing them, and --comment has it leave its findings as comments. You can also set an effort level from low up to max, which trades time against depth.

In practice I use the local command as a pre-flight. Run it before you open the pull request, clear the obvious things, and let human reviewers spend their attention on the parts that need judgment. That sequencing is the whole benefit, and it works the same way the automation split does in [Claude Code GitHub Actions](/blog/claude-code-github-actions).

The failure mode with automated review is not that the tool is bad. It is that people switch everything on at once, drown in comments, and quietly stop reading them within a fortnight. Slow is genuinely faster here.