Claude Code Review Goes GA: Never Blocks PRs, Yet Anthropic Enforces Hard Gates Internally

Anthropic's code review product Code Review ended its research preview phase on October 15 and is now generally available (GA) to Team and Enterprise organizations. But there's an intriguing contrast: in Anthropic's own Claude Code repository, a PR cannot be merged as long as any review finding remains unresolved; yet in the version sold to customers, reviews never fail checks and never approve or block your PR. This difference is not an oversight but a deliberate split between product positioning and internal practice.

Product-level design: reviews provide information, not decisions

According to the official announcement, Code Review is now available to Claude Team and Enterprise organizations. Admins can choose Quick, Standard (default), or Deep review depth for each repository; compared to the preview phase, most reviews are now about 3x faster, dropping from roughly 20 minutes to 6 to 10 minutes.

Mechanically, multiple agents read the diff and surrounding code in parallel, then a verification pass discards false positives before results are published. Inline comments appear on the PR, along with a check run named Claude Code Review, where each finding is tagged as Important, Nit, or Pre-existing. Reviews run on Anthropic's infrastructure with read-only permissions and never build or execute your code.

The product documentation is very explicit: "Reviews never approve or block your pull request, and the check run never concludes with a failure." This matches the official team blog's wording—approving a PR is always "a human decision; the product publishes findings, not approvals."

In other words, if you want findings to actually block merges, you need to configure rules on your repository side. The documentation offers two approaches, detailed later.

check run is an object in GitHub's Checks API used to report the results of automated tasks (such as CI, lint, security scans) to a PR or commit. Each check run has a status (queued, in_progress, completed) and a conclusion (success, failure, neutral, cancelled, etc.), and can carry detail text and annotations. Branch protection rules can require certain check runs to be completed with a success conclusion before merging. The Claude Code Review check run in this article is such an object—it always ends with a non-failure conclusion, so it never inherently blocks merges; to achieve blocking, you need an external script to parse its detail text or rely on other PR states (such as unresolved conversations) to do so indirectly.

Internal practice: risk tiers + hard gates, completely different from the commercial product

Anthropic's own repository rule is: "A PR cannot be merged as long as any bug review or security review finding remains open." The gap between these two worlds is laid out in the official's own words.

Supporting this internal process is a risk-tier classifier. It reads each change and assigns a risk tier: low risk (docs, copy, internal features, incremental changes behind flags) can merge with zero human approval after automated review and security checks pass; medium risk (ordinary product changes, caching, auto-updaters, system prompts) requires one human approval; high-risk code requires two.

The team blog also lists several rules worth copying even if you don't buy the product: "The change itself determines the tier, not the author," "Whoever initiates the change owns it," "One approval covers only one specific commit," "Certain paths must involve humans, including paths marked sensitive by owners and any CI workflow files."

More noteworthy is the team's candor about its own limitations: they "don't yet have circuit breakers that tighten approvals when metrics change," and engineers want these mechanisms built before more code moves to zero-human merges.

OWNERS markers (OWNERS files) are a common permission convention in large code repositories, originating from Google's internal practices and later widely adopted by open-source projects like Kubernetes. Specific directories or files in a repository can carry an OWNERS file listing individuals or teams with review or approval rights for that path. When a change touches these paths, approval from the corresponding owners is required to merge. Anthropic's internal rule that "paths marked sensitive by owners must involve humans" is exactly this kind of mechanism. Its purpose is to refine "who is qualified to approve" from global roles down to the path level, preventing people unfamiliar with a module from casually waving through high-risk changes.

Effect data should be viewed with caution

The team blog offers persuasive numbers: Claude wrote about 90% of Claude Code's own code; from June to September, the number of merged PRs in the Claude Code codebase more than doubled, while the rollback rate dropped by over 40%. The goal is for "most PRs in the Claude Code repository to merge with at most one human involved, without increasing rollbacks or incidents."

But these numbers have two caveats: they are Anthropic's self-reported data about its own repository without baseline figures; and according to The Next Web, Anthropic's performance claims for the product have not been independently tested. For teams considering adoption, this is evidence worth consulting but not directly extrapolating.

How to enforce hard gates in your own repository

By default, the product does not block merges; the documentation offers two paths to turn it into a hard gate.

Option 1: Require all conversations resolved. GitHub branch protection rules can require all comments on a PR to be resolved before merging. Since findings are posted as inline threads, unresolved threads will block merging. Two notes: replies alone cannot close findings—you need to push a fix so the next review resolves them, or mark them resolved manually; additionally, this rule covers all threads, including nits and human comments, and doesn't work for findings that GitHub cannot accept as inline comments—such findings only appear in the Files changed tab annotations and the check run's detail table.

Option 2: Gate only Important findings. At the end of the check run's detail text there is a machine-readable verdict line that gh can parse. The normal key counts Important findings, including those still unresolved from previous reviews. The script chains two gh api calls and exits non-zero when unresolved Important findings exist.

One key implementation detail: this script must run as a pre-merge step when the Claude Code Review check has already completed, not triggered when the PR is opened or pushed. Reviews take minutes; a job triggered too early won't find a completed run and will fail every PR. The script also deliberately adopts a fail-closed policy—the documentation recommends treating a missing verdict line as "no conclusion rather than zero findings," and "some completed reviews also lack this line." So occasionally clean PRs may need an @claude review comment to pass the gate. The author also admits the script hasn't actually been run against a real Code Review check.

Before enabling either gate, protect the default branch first. REVIEW.md can lower severity levels, and Option 2 counts exactly severity levels, so who can edit this file matters greatly. Code Review only reads REVIEW.md from the PR's base branch or default branch, never from the PR's own changes, so a PR cannot loosen its own review. Rules that lower levels, exclude paths, or limit nit counts are only adopted from the root REVIEW.md when the default branch is protected. The local /code-review reads CLAUDE.md, not REVIEW.md.

fail-closed and fail-open are a pair of principles in security and reliability design. fail-closed means that when the system cannot make a judgment or an exception occurs, it defaults to the conservative behavior of denying/blocking; fail-open defaults to allowing. In the merge gate script in this article, fail-closed means that if the verdict line cannot be parsed (perhaps because the review hasn't completed, the run was skipped, or the format changed), the script treats it as "no conclusion" and exits non-zero, thereby blocking the merge. The benefit is that unreviewed code cannot slip through; the cost is that occasionally clean PRs are mistakenly blocked and require manual re-triggering of the review. Which strategy to choose depends on the team's trade-off between risk of letting things through and friction cost.

Cost structure: token-based billing, default settings easily inflate spend

There is no fixed per-review price. Reviews are billed by token usage through usage credits, separate from plan-included usage, and charged to the organization account. During the preview, according to The Next Web, each review cost between $15 and $25.

Watch out for the default setting: newly added repositories default to triggering a review "after every push," so costs multiply with the number of pushes. The documentation recommends piloting with a few repositories using "once after PR creation" or manual mode, monitoring the Average cost column, and setting a monthly spend cap. Once credits run out, reviews are skipped and a comment explaining why appears on the PR. Qualifying Enterprise organizations can apply for at least $10,000 in Code Review credits before January 15, 2027, subject to specific terms.

usage credits are the pay-as-you-go billing unit Anthropic uses for its API and some value-added features, accounted separately from the usage allowance included in subscription plans. Each Code Review review consumes input and output tokens for model inference, so costs vary with diff size, review depth (Quick/Standard/Deep), and trigger frequency—there is no fixed per-review price. Billing is settled through the organization account; admins can view metrics like Average cost in the console and set monthly spend caps. When credits run out, related features are skipped rather than erroring, which requires teams to plan budgets in advance to avoid losing review coverage during critical merge windows.

Another layer before the PR: local pre-checks

Code Review starts working once a PR exists, but Anthropic's first line of defense comes earlier: Claude runs tests, builds, and linters before the PR is opened, with a sub-agent reviewing the diff in a fresh context. The team blog notes that Claude Code creator Boris Cherny estimates this verification can improve final results by two to three times.

This is exactly where local tools and IDEs come in. The developer tool ecosystem around Claude Code (such as IDEs supporting branch isolation, saving agent actions turn by turn, and reviewing changes with risk tags before committing) targets this "before the PR" gap. Note that such tools do not run Code Review, do not replace CI, and have no affiliation with Anthropic.

Would you dare use zero-human approval?

Anthropic's own repository already allows owners to decide which low-risk changes (for example, incremental changes behind flags) can merge on automated checks alone—and that's before the circuit breakers engineers want are in place.

For teams using the product, the core question becomes: are you willing to let a classifier decide risk tiers for your repository? Or does every PR still need a human?

From an engineering practice perspective, the real value of Anthropic's case isn't the product features themselves but the gradual path it demonstrates: first use review findings to increase information density, then turn them into gates via repository rules, and only consider opening up zero-human merges once data is sufficient. For most teams, copying the "zero-human" approach directly before tightening branch protection and REVIEW.md permissions is too risky—especially when self-reported data and independent verification remain far apart.

An AI reviewer is essentially an LLM feature running in production, and Anthropic operates it to that standard: past incidents become daily regression tests in an eval set, and noise levels are measured by how humans actually handle each comment. If your team plans to put an AI reviewer on PRs, this observability and evaluation work should be planned before the bill arrives.

One-line Summary

Claude Code Review is now GA, but the product doesn't block merges—a deliberate contrast with Anthropic's internal hard gates.

Paragraph Summary

Anthropic's Code Review ended its research preview on October 15 and is now GA for Team and Enterprise organizations. The product offers Quick, Standard, and Deep review depths, is about 3x faster than the preview, and cuts each review to 6–10 minutes. Multiple agents read the diff and surrounding code in parallel, a verification pass discards false positives, and then inline comments and a check run named Claude Code Review are published on the PR, with findings graded Important, Nit, or Pre-existing. But by design the review never approves or blocks a PR, and the check run never fails; meanwhile Anthropic's own repository forbids merging while bug or security review findings remain open, and requires zero/one/two human approvals for low/medium/high risk respectively. The article also covers two DIY hard-gate approaches, the token-based cost structure, and a cautious stance on effect data lacking independent verification.