Claude Code Review Alternative for Gating Merges

Claude Code Review can't stop a merge on its own. Anthropic's docs say a review never approves or blocks a pull request, and its check run concludes as neutral or skipped, never as a failure. To gate a merge on it, you parse its severity counts in your own CI. The other route is a reviewer whose required check is itself the gate, such as Warpway, which can run on the same pull requests.

What Claude Code Review decides, and what it leaves to you

Anthropic launched Code Review on March 9, 2026, as a research preview for Team and Enterprise plans. Several agents examine the diff and the surrounding code on Anthropic's infrastructure. A verification step filters out false positives, and the remaining findings are posted as inline comments ranked 🔴 Important, 🟡 Nit or 🟣 Pre-existing, along with a check run named Claude Code Review. For merge policy, these points matter:

• The check never fails. The pull request docs say it "never concludes as a failure, so a finished review doesn't fail a required check." If you make it a required check, merges wait for a review to finish, but the review can't fail them.
• It never approves. From the launch post: "It won't approve PRs — that's still a human call."
• It reads code but doesn't run it. A review works "without building or running your code."
• Its instructions come from the base branch. REVIEW.md is read from the base or default branch, never from the pull request's own changes.
• You pay per review. It is billed on token usage through usage credits, with no flat price. The launch post said reviews "generally average $15–25". Repositories you add start at After every push, which multiplies cost by the number of pushes.

It isn't available to organizations that use Zero Data Retention or the HIPAA configuration, and it reviews GitHub repositories only, including GitHub Enterprise Server.

When an advisory reviewer is enough

Advisory review works when a person already reads the change and decides whether it merges:

• Required human approvals are already your gate. The findings inform the reviewer, and nothing is lost because the bot can't block.
• You want findings acknowledged, not enforced. If branch protection requires conversation resolution, each finding's thread must be resolved before merge, as Anthropic's docs note. They also note that you can dismiss a finding by resolving its thread without changing code, so a resolved thread doesn't show that the issue was fixed.
• Reviewers keep up with PR volume. If so, a second opinion on bugs is all you need.

It stops being enough when approval is the bottleneck. Coding agents open more pull requests than people can read line by line, and you want low-risk changes to clear on their own while risky ones wait. It also falls short when the open issue is a decision rather than a bug, such as whether revoking an admin role should end active sessions immediately. A comment with a severity label doesn't send that question to the person who can answer it.

Gating on Claude Code Review in your own CI

Anthropic documents a way to read the result. The last line of the check run's Details text is an HTML comment holding severity counts as JSON, such as <!-- bughunter-severity: {"nit":1,"normal":2,"pre_existing":0} -->, where normal is the number of Important findings. Handle the cases in this order:

1. If the title starts with Code review not repeated, earlier Important findings are still open. Fail.
2. If the title ends with no new changes, pass.
3. If normal is above zero, fail.
4. If there's no severity line, there's no verdict. That isn't the same as zero findings.

Reviews finish asynchronously; Anthropic's testing put the average at around 20 minutes. Rather than polling, trigger on GitHub's check_run event. GitHub runs check_run workflows only from the default branch, and their GITHUB_SHA is the default branch head, not the pull request's head. So the job writes a commit status onto the reviewed commit:

# .github/workflows/claude-review-gate.yml (must be on the default branch)
name: Claude Code Review gate
on:
  check_run:
    types: [completed]
permissions:
  checks: read
  statuses: write
jobs:
  gate:
    if: github.event.check_run.name == 'Claude Code Review'
    runs-on: ubuntu-latest
    env:
      GH_TOKEN: ${{ github.token }}
      REPO: ${{ github.repository }}
      SHA: ${{ github.event.check_run.head_sha }}
      RUN_ID: ${{ github.event.check_run.id }}
    steps:
      - name: Turn the review into a pass/fail status
        run: |
          title="$(gh api "repos/$REPO/check-runs/$RUN_ID" --jq '.output.title // ""')"
          state=failure
          desc="No verdict from Claude Code Review"
          if [[ "$title" == "Code review not repeated"* ]]; then
            desc="Earlier Important findings still open"
          elif [[ "$title" == *"no new changes" ]]; then
            state=success
            desc="No new changes since the last review"
          elif counts="$(gh api "repos/$REPO/check-runs/$RUN_ID" --jq '
              (.output.text | split("\n") | last
                | scan("^<!-- bughunter-severity: (.*) -->$")[0] | fromjson)?
              // error("no severity line")')"; then
            important="$(jq -r '.normal' <<<"$counts")"
            if [[ "$important" == "0" ]]; then
              state=success
              desc="No Important findings"
            else
              desc="$important Important finding(s) open"
            fi
          fi
          gh api "repos/$REPO/statuses/$SHA" \
            -f state="$state" -f context="claude-review-gate" -f description="$desc"

Then require claude-review-gate in your branch ruleset. This gate has limits:

• Every head commit needs a review. If the status never arrives, the PR waits. Under Once after PR creation or Manual, later pushes don't start a review, so in practice the gate needs After every push, which costs a review per push.
• Drafts and forks are skipped. On a fork PR, someone with write access has to comment @claude review.
• Running out of budget stops reviews. When the Code Review spend limit, the organization's spend limit or the credit balance runs out, reviews are skipped and the gate waits.
• Resolving a thread dismisses a finding. Open findings from earlier reviews count until their threads are resolved, so the gate is only as strict as your rules on who may resolve them.
• It answers one question. The gate only checks whether any Important findings are open. It doesn't approve or ask anyone anything. Path-specific rules can go in REVIEW.md or CLAUDE.md, including copies in subdirectories that apply to changes under that path. Subdirectory REVIEW.md files are read only when the branch they're read from is protected. Instructions that lower severity, exclude paths or cap nits are honored only from the root REVIEW.md on a protected default branch. These rules change what gets flagged and marked Important, but the gate's own pass/fail rule stays the same everywhere.

Other ways to get a reviewer GitHub can act on

Here is how three other options can affect merging. The details come from each vendor's docs as of October 2026:

The Action is the closest alternative that still uses Claude: it runs on your runners with your prompt, and your CI decides what fails. Copilot and CodeRabbit gate through GitHub review decisions, so they plug into rules that require approving reviews. For a wider comparison, see AI code review tools that approve pull requests.

How Warpway's trust levels fill the gap

Warpway is a GitHub App that reviews each eligible pull request through lenses: Correctness, Security, Testing / Reliability and five more. It clears what it can with evidence. Whatever it can't resolve becomes a specific question, sent in GitHub or Slack to the person most likely to know. Its gate is the Warpway / Review check, which behaves according to the repository's trust level:

At Gate, you make Warpway / Review a required check (see merge gating). The check concludes failure if there are open blocking findings, a required lens is Incomplete, required CI fails, or the configuration is invalid. If only questions remain, it concludes action_required and names who it's waiting on. Deterministic code decides whether the policy is satisfied, not a model. Warpway fails closed: if a model or tool fails, the lens is marked Incomplete, never Cleared. Like REVIEW.md, the policy is read from the base branch.

Auto-approval is off by default. It needs the Team plan, an Owner turning it on for both the organization and the repository, trust level 4, and a policy such as:

version: 1
merge_gate:
  block_on_severities: [critical, high]
  required_ci_checks: [build, unit-tests]
auto_approve:
  enabled: true
  docs_tests_only: true
  max_changed_lines: 300
  excluded_paths: ["auth/**", "migrations/**"]
  required_ci_checks: [unit-tests]

Warpway may not fit if:

• You won't pay for gating. Gate and the levels above it need the Team plan, listed at $30 per developer per month. The Free plan stops at Assist, where the check is always neutral.
• You need a Claude-based reviewer. The hosted service runs every review step on OpenAI's GPT-6 Sol.
• You're not on GitHub, or you want merges automated. Warpway works only with GitHub and never merges. It also doesn't report on merge-queue groups, so don't require its check in a ruleset that gates a merge queue.
• You need the reviewer to run your code. It runs nothing unless you approve runtime verification profiles, which run in your own GitHub Actions.

Warpway's case studies are replays: merged open-source PRs run through Warpway on October 7, 2026, as they stood before merge. One replay flags the Hono c.json(undefined) regression, a change that was reverted after four days.

Running Claude Code Review and Warpway on the same pull request

They are separate GitHub Apps with separate checks, so they don't conflict. To keep Claude's findings and add a gate:

1. Leave Claude Code Review unrequired, or require the claude-review-gate status from the workflow above.
2. Raise the repository to Gate in Warpway and require Warpway / Review.
3. To make Warpway's merge verdict wait for Claude's review, add Claude Code Review to merge_gate.required_ci_checks. That list counts neutral as passing, so Warpway waits for the review to finish without failing on its findings. Only do this with After every push, or later commits never get Claude's check and the policy keeps waiting.
4. In a repository that auto-approves, keep Claude Code Review out of both required_ci_checks lists. Auto-approval needs every listed check to conclude success, and neutral doesn't count. You don't lose anything by leaving it out: auto-approval already won't approve while any other check on the commit is running or failing.

Warpway reads CI results reported as check runs, not as commit statuses, so it can't see claude-review-gate. Require that status directly in your ruleset.

Choosing

• Human approval is already your gate: keep Claude Code Review as it is, and optionally require conversation resolution.
• You want "no Important findings" enforced: use the check_run workflow above with After every push.
• You want Claude on your own runners, with your own prompt: use the Claude Code GitHub Action and add a pass/fail step.
• You want a policy gate, questions sent to the right people, and auto-approval for narrow kinds of change: run Warpway at Gate, move low-risk repositories to Clear or Auto-approve, and keep Claude's comments running alongside it if you find them useful.