Claude Code review can mean a local session or Anthropic’s managed GitHub review service. Choose the workflow before configuring it: the managed service has organisation requirements, separate billing and repository settings, while a local review runs in your Claude Code session.
Documentation checked October 21, 2026. This guide describes documented behaviour; it does not report a hands-on product test.
On this page
Identify the review you need
Anthropic’s Code Review overview separates the managed service from other ways to review code. The managed service examines GitHub pull requests and posts inline findings. A local review is started from your own Claude Code session.
For a team evaluating automation, the first question is where the result must appear. A developer inspecting a branch may need a local second opinion. A repository workflow may need comments attached to a pull request and a consistent trigger policy.
Do not infer that subscribing to an individual coding plan enables the organisation-level service. Check the current eligibility and billing documentation for the workflow you intend to use.
What the managed review does
The overview describes multiple agents reading a diff and surrounding code, followed by verification, deduplication and severity ranking. Results appear as comments, a summary and a check run on the pull request.
Anthropic says the service reads code without building or running it. It does not approve or block the pull request, and a review with no findings does not establish that the code is error-free or secure.
That distinction changes a release checklist. Keep automated review, executed tests and authorised merge approval as separate evidence. A green review check cannot stand in for a missing test run.
Check organisation eligibility first
The managed service is documented for Team and Enterprise organisations. Anthropic lists additional limitations involving data-retention configurations, HIPAA configuration and customer-managed encryption keys. Review the current availability section before installing anything.
The setup instructions require an appropriate organisation owner and permission to install the Claude GitHub App. The app’s installation permissions are broader than the code-reading activity inside a review.
For an internal evaluation, record which repositories the app can access and who can change that selection. Treat installation as an access decision; do not turn a review experiment into unexplained access to every repository.
Choose when reviews run
Anthropic documents repository settings for reviewing once after pull-request creation, after pushes, or only on request. Manual review uses the documented comment command:
@claude review
Use the current setup and pull-request documentation for the exact trigger conditions. The command is a request to start a review, not an instruction to approve or merge the code.
A team trying the service can start with a small, representative repository and a deliberate trigger choice. Compare review usefulness across ordinary changes and riskier changes before expanding. That is a suggested evaluation process, not a product requirement.
Give the reviewer stable instructions
Anthropic documents CLAUDE.md and REVIEW.md as ways to guide review. Keep project conventions and review-specific expectations explicit. The memory-file guide explains how to write useful repository context.
Prefer a rule that points to observable behaviour: “A migration must preserve the existing identifier mapping” is more actionable than “Be careful with databases.” Link a repository rule to the file, interface or invariant that supports it.
Do not load the review instructions with every preference a team has ever expressed. Review comments become harder to assess when an important correctness issue and a cosmetic preference receive indistinguishable wording.
Evaluate a finding before changing code
A useful human review can ask four questions:
- Which changed line or behaviour does the finding concern?
- What concrete input or execution path would reach it?
- What evidence supports the claimed result?
- What test or inspection can confirm the proposed correction?
For example, if a comment claims a null input causes a crash, inspect the input contract and the caller before applying a suggested guard. The input might be impossible, or the guard might conceal an upstream error. Conversely, a plausible explanation should not be dismissed just because the code compiles.
Document the resolution in the team’s ordinary review process. Do not treat the number of comments as a quality score.
Keep cost and approval separate
The setup help page states that Code Review usage is billed separately through usage credits. Review triggers affect how many reviews run, so check the organisation’s spend controls before choosing an every-push policy.
A review finding is also separate from approval to make a change. The same discipline applies to Claude Code subagents and sandbox permissions: inspect what a tool can do and what evidence its output establishes.
