Copilot Code Review Is Comment-Only and Can Never Block a Merge, Docs Say

GitHub Copilot's code review will never stand between a pull request and a merge. As a dev.to analysis highlights, GitHub's own documentation is explicit on this point: Copilot always submits a Comment review — never Approve, never Request changes. It does not count toward required approvals, and it cannot block a merge.

The post's author argues this is a sensible safety boundary, but also the single most misread fact in AI code review procurement. Vendor decks promise "automated code review," and buyers mentally upgrade that to "quality gate." Those are different products, and the distinction reorders any shortlist.

Four checkpoints, not four competitors

The dev.to piece frames a governed code change as four checkpoints that different tools staff differently, even though their outputs all look deceptively similar because they all produce comments:

• Before commit: the author inspects staged changes in an IDE or CLI and removes obvious defects.
• Repository investigation: a reviewer traces symbols, callers, history, tests and cross-repo dependencies to size up the blast radius.
• Pull-request triage: automation reads the diff, description and repository guidance, posts a summary with targeted comments, and re-reviews when the branch updates.
• Merge governance: branch rules require tests, static analysis, security scans, designated human approvals and auditable exceptions.

The author's analogy for checkpoint three is an emergency-room triage nurse: able to flag severity and hand the doctor a useful summary, but not authorized to perform surgery. The value is coverage and ordering; the authority stays elsewhere.

Where each tool actually sits

The post contrasts four products along these checkpoints.

CodeRabbit reviews pull requests on creation and updates across GitHub, GitLab, Azure DevOps and Bitbucket. Its pre-merge checks can warn or error, and with the Request Changes workflow an error-level check can block a merge until the issue is fixed or explicitly overridden.

GitHub Copilot is broader than completion, spanning local review in VS Code, Visual Studio, JetBrains IDEs and Xcode, plus PR review on GitHub triggered manually, via CLI or API, or automatically through repository settings. Customization runs through .github/copilot-instructions.md, path rules under .github/instructions/, and shared conventions in AGENTS.md. The post flags two documented caveats: if the Actions runners behind the agentic capabilities are unavailable, a review is still generated but without the context-gathering abilities, and by default review may happen only when the PR opens, so teams should verify whether new pushes trigger re-review.

Sourcegraph Cody targets a different bottleneck: insufficient context. Keyword search and the code graph let a reviewer find every caller of a changed authorization helper across repositories, improving the evidence behind a human decision — which is not the same as a bot reviewing every PR. Broad search access is both the tool's value and a permissions risk across team boundaries, the author warns.

CodeBuddy is best understood before the pull request exists, oriented toward Chinese-language requirements and comments with IDE, extension, CLI and Tencent Cloud workflows. Within the material reviewed, the author found no evidence of an automated, repository-wide review-and-gate workflow equivalent to CodeRabbit's, and advises validating any claimed PR integration separately.

False positives are a queue cost

Every wrong comment spends reviewer attention and teaches developers to dismiss the bot, the post argues; once people mechanically resolve every AI thread, governance degrades into ritual. It recommends tracking AI comments in four buckets — confirmed defect, useful improvement, optional preference, incorrect — reviewing that distribution every two weeks and deleting rules that generate noise. New checks should start in warning mode, with only stable, high-value ones promoted to blocking. Style belongs to formatters, linters and type checkers; deterministic scanners should own dependency vulnerabilities and leaked secrets, while model judgment is spent on correctness, security, edge cases, compatibility and missing tests.

Evaluate on replayed history, not demos

Giving each product a different showcase task produces marketing rather than evidence, the author writes. The alternative: pick one representative repository, replay 8 to 12 sanitized historical pull requests with known review outcomes — including an edge-case defect, an authorization regression and one unconventional implementation that turned out correct — and hide the original reviewer comments. Then measure actionable precision, critical-issue recall, noise cost, context quality, re-review behavior and permission exposure.

Why it matters

Teams adopting Copilot's review expecting enforcement will discover the gap during an audit, not while reading the docs. Finding a possible defect and preventing a merge are separate operations: the first is probabilistic analysis, the second requires explicit policy, a visible status, a controlled override and an audit trail. Copilot supplies evidence; the gate stays mechanical, built from branch protection and human approvals. Knowing which checkpoint each product actually staffs is most of the buying decision — and it prevents paying for a surgeon when the job only needed a nurse.