An AI agent can safely hold pull-request approval authority only with repo-aware review scope, a measured precision threshold at the blocking gate, an auditable record of every approval, and a human who sees exceptions before merge.
TL;DR
One vendor now documents an approving review from its agent that counts toward branch protection, so a wrong approval can ship a defect. A reviewer that reads only the diff misses cross-file breakage. Autonomous code review approval is defensible only behind repo-aware scope, a measured precision bar, retained evidence, and human review of exceptions.
An autonomous reviewer posts an approving review, and branch protection counts it toward the required approvals. The merge control then clears. The author then force-pushes a rebased branch that rewrites the retry logic in a shared client. Because the repository never enabled stale-approval dismissal, the approval stays attached to the pull request and the change merges with commits the agent never read.
This guide is for engineering leaders and platform owners, plus security and compliance stakeholders deciding whether an agent may hold approval authority at all. The scope is review decisions in Cosmos, Augment Code's unified cloud agents platform available on all paid plans, within continuous integration (CI). Editor-side chat is out of scope, as is vulnerability remediation; the question is review quality and whether the reviewer catches what it should before approving.
What Autonomous Code Review Approval Means
Autonomous code review approval is the end-to-end path from a repository event to a formal review state that a merge gate honors without a human in between. A pull request opens or receives a push, which triggers the agent. The agent reads the diff plus whatever surrounding code its scope allows before deciding whether the change is safe. On GitHub, the decision takes one of two forms: a Comment review, which is advisory, or an Approve review, which the repository's required-approval rule can count.
GitHub Copilot code review leaves a Comment review by default; since September 1, 2026, a public preview lets it submit an opt-in approving review that satisfies the repository's required-approval rule the same way a teammate's approval does. The merge gate itself has two independent legs. Required reviews and required status checks are separate conditions, and GitHub auto-merge waits for both to pass. An approval does not bypass CI, but with auto-merge enabled, it is the last judgment standing between a green pipeline and the default branch.
Why Approval Authority Is Different From Review Comments
An approving review changes who bears the cost of a reviewer's mistake. When an agent only comments, a missed defect still meets a human approver, and a false positive costs a few minutes of triage. When the agent's approval satisfies the required-approval rule and auto-merge is on, a false approval ships the defect.
Review comments from PR-Agent, Devin Review, Claude Code, and Codex passed the c-CRAB benchmark's executable-test oracle at rates between 20.1% and 32.1% on 184 pull request instances. Those figures measure whether review comments corresponded to test-backed defects; they do not measure false-approval rates at an autonomous merge gate or transfer directly to one team's codebase. The repository records the human approver's identity, and the organization holds that approver accountable. Stale-review dismissal separately revokes an old approval after a push and requires a new qualifying approval.
The Review Scope Required: Targeted Repository Context
An approval is only as trustworthy as the context the reviewer read before granting it. Scope sets a ceiling on what a reviewer can catch, and a diff-only reviewer has the narrowest scope of any option.
- Lint and static analysis check the changed lines against fixed rules, while semantic review of the diff reasons about intent inside the changed hunks.
- Repo-wide review follows the callers, consumers, and schema owners the diff touches without editing.
The last tier can see that a renamed field in a shared client breaks consumers the pull request never opened, which is why diff-only reviewers miss breakage that crosses file boundaries. At a merge gate, that scope gap creates unreviewed risk because cross-file breaks outside the reviewer's view cannot inform its verdict.
Repo-aware review retrieves structurally relevant context, not just more undifferentiated text. The SWE-PRBench preprint, a March 2026 arXiv paper that scores eight frontier models on a 100-PR stratified sample drawn from its 350-PR corpus, found that every model's detection degraded monotonically as context grew, a pattern the paper attributes to possible attention dilution.
Useful whole-repo context retrieves structurally related code through dependency relationships and relevant commit history. In Cosmos, the Context Engine indexes hundreds of thousands of files across repositories and maps call relationships and cross-repo dependencies, so a reviewer can retrieve consumers of a change instead of reading the whole tree. Retrieval cannot surface a consumer in a repository the index never ingested, so approval authority belongs only to changes whose consumers live in indexed repositories.
The Precision Threshold Required at a Blocking Gate
Recall is the share of real defects in a corpus that the reviewer flags; precision is the share of reviewer comments that match a golden comment. In advisory review, recall matters more because a missed defect is gone, but a false positive costs a human a minute. That tradeoff supports recall-first review as the default posture for comments.
At a blocking gate, the weighting flips. Every verdict now carries a consequence, either a blocked merge or an approval. A reviewer that flags too much blocks good changes until developers route around it, and one that approves too freely ships defects. Precision makes a blocking decision cheap enough to keep, and recall makes an approval safe enough to trust; that gate-type split is covered in the AI code review accuracy analysis.
Augment Code published its seven-tool benchmark in December 2025 and updated it on June 18, 2026. It covered 50 pull requests across five open-source repositories: Sentry, Grafana, Cal.com, Discourse, and Keycloak. The benchmark results put Augment Code Review at 65% precision and 55% recall. Its F-score was 59%. That is, first-party evidence scored against a golden comment set Augment expanded and corrected itself.
In a separate measurement, Augment's precision reached 47.0% in a March 2026 run that used a large language model (LLM) as a judge on 10 pull requests, which shows how the corpus and scorer affect the result. For Cosmos Code Review, the team must derive a blocking threshold from local data by labeling and counting reviewer approvals in its own repositories.
The Audit Trail Required to Evidence an Approval
An autonomous approval needs a chain of custody that lets an auditor reconstruct the decision from ticket through merge. An audit-ready record preserves five fields, from the ticket that started the change to the commit that closed it.
- Change identity: Preserve the ticket and pull request.
- Trigger evidence: Record the repository event that started the review.
- Reviewed code: Preserve the commit Secure Hash Algorithm (SHA) value and the code state the reviewer read.
- Decision record: Retain the reasoning and formal approval event.
- Merge evidence: Record the final commit and merge event.
When the review runs in an ephemeral CI container, the team must retain those fields outside the container. For Cosmos Code Review, writing a stable review-record identifier into the approval body closes the chain between the pull request and the retained evidence.
The System and Organization Controls (SOC) 2 change-management criterion, CC8.1 in the American Institute of Certified Public Accountants (AICPA) Trust Services Criteria, requires the entity to authorize, test, approve, and implement changes. It does not prescribe independent or peer review. Segregation of duties sits in CC5.1, which allows alternative control activities.
International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 27001:2022 control A.8.32 does not prescribe a change approval mechanism. Whether an automated approval satisfies SOC 2 or ISO/IEC 27001 depends on the organization's documented procedure, delegated authority, system auditability, and auditor evaluation.
Two supply-chain instruments exclude bot review outright. The OpenSSF Scorecard Code-Review check counts only human review. The SLSA v1.1 threats from Supply-chain Levels for Software Artifacts (SLSA) state that all changes require review by two people, including changes authored by robots. A team scoring against Scorecard or SLSA cannot count an automated approval as review.
The Human-in-the-Loop Fallback: Exceptions Before Consequence
The safe default is recall-first review with a human who sees exceptions before merge. A human who re-reads every change gives back the throughput the agent added; a human who learns of the exception from a revert has turned a review control into an incident process. Scope-based routing satisfies both because the agent approves inside a defined envelope, and anything outside it stops and waits for a named person.
File globs and protected paths route changes that touch authentication, billing, schema migrations, infrastructure, and CI configuration to a human team, regardless of the agent's confidence. GitHub made its required reviewer rule generally available on February 17, 2026. It enforces a required number of approvals from designated teams, so the ruleset can carry that routing, not the agent.
Greptile launched its beta auto-approve on June 26, 2026, and requires a 5/5 confidence score plus a risk level Greptile classifies as low. Greptile excludes changes that touch authentication, secrets, and billing code from auto-approval, regardless of confidence score. A Cosmos Code Review deployment should preserve the same human-routing boundary for high-risk paths.
Which Tools Can Approve, and Which Only Comment
Copilot, CodeRabbit, Qodo Merge, and Greptile all default to comments, so a platform team must deliberately configure approval authority. The documented merge-gate mechanism differs by vendor.
| Tool | Default review state | Formal approving review | Controlling setting | Documented merge-gate mechanism | Blocks merge by default |
|---|---|---|---|---|---|
| GitHub Copilot code review | Comment | Yes, opt-in public preview since September 1, 2026 | Enterprise, organization, or repository setting | Required-approval rule, same as a teammate's approval | No |
| CodeRabbit | Comment | Yes, after a team enables it | reviews.request_changes_workflow (default false) | Required reviewer that can block or unblock merging; separate CodeRabbit check run | No |
| Qodo Merge | Comment | Yes, in hosted v1 documentation for GitHub | enable_auto_approval or approve_pr_on_self_review (default false); current v2 documentation does not state whether the v1 options remain active | Adds itself as a reviewer on self-review check-off | No |
| Greptile | Comment | Yes, beta since June 26, 2026 | autoApprove.enabled (default false) | Optional statusCheck (default false) posts a GitHub status check in place of a comment | No, until a team requires the check |
| SonarQube Cloud and Server | Comments plus commit status | No | Quality gate | Required status check SonarCloud Code Analysis or SonarQube Code Analysis | No, until a team requires the check |
| Amazon CodeGuru Reviewer and Amazon Q Developer | Comments only | No | None | Not documented | No |
Only Copilot's documentation states that its approval satisfies the required-approval count. CodeRabbit documents a merge-blocking path through a required-reviewer role, and Greptile documents a status-check option that posts a pass/fail GitHub check a team can mark required. Neither vendor explicitly states that its Approve review increments the numeric required-approval rule. Qodo's hosted v1 documentation leaves the same required-approval question open, and the migration to v2 has not settled it. Teams should confirm each behavior in a staging repository.
Where Autonomous Approval Goes Wrong
Wrong approvals reach the default branch through ruleset and agent-configuration failures, not through a single model behavior.
- Stale approval after a force-push: GitHub records the diff state at the moment of approval, and the approval survives a later push unless the ruleset enables stale dismissal. This creates a time-of-check-to-time-of-use (TOCTOU) gap where reviewed code changes between check and use. Enable
dismiss_stale_reviews_on_push, and submit the review with thecommit_idthe agent read so the review references a fixed SHA and not whatever HEAD becomes. - Approval standing while tests fail: An approving review and a status check are independent conditions, so an agent approval sits green beside a red pipeline until someone merges by hand. Require the CI check in the same ruleset; GitHub requires checks to pass on the latest commit, and auto-merge waits for both conditions.
- False approvals from diff-only scope: A reviewer that reads only the hunks cannot evaluate consumer breaks outside those hunks. Grant approval authority only inside indexed repositories, and route shared-interface changes to a human.
- Cry-wolf noise: A reviewer that blocks on low-priority findings trains developers to dismiss its threads, and the habit carries over to the one thread that mattered. CodeRabbit changed its auto-approval behavior on July 10, 2026, so grouped or lower-priority feedback no longer blocks. Tune the blocking threshold so only actionable findings block, and track the dismissal rate on the agent's threads.
These controls bound the reviewed commit, preserve independent CI enforcement, widen relevant scope, and keep blocking feedback actionable.
How to Scope an Agent for Approval Authority
Run Cosmos Code Review in advisory mode on the repositories where you intend to grant approval until you have labeled a sample of its verdicts. Label the pull requests it would have approved as safe or defective. Use reverts and documented post-merge fixes as ground truth, then compute the false-approve rate.
Require repo-aware scope for Cosmos before you flip the setting. Confirm which repositories the Context Engine has indexed; a shared software development kit (SDK) consumed from an unindexed repository stays human-gated. Every Cosmos approval should point to the commit the reviewer read and require the CI check in the same ruleset with dismiss_stale_reviews_on_push enabled.
Route high-risk paths to people. Write those protected paths as file globs in the ruleset's required reviewer rule, and route changes above the configured risk threshold to a person. Have the reviewer post a stable evidence identifier in its approval body, and export the retained audit record to the organization's security information and event management (SIEM) system when that integration exists.
Before You Grant Autonomous Code Review Approval
The tradeoff is throughput against a bar most merge pipelines were never engineered to meet. An agent that approves the low-risk share of a team's pull requests removes hours of human review at the price of an unmeasured false-approve rate, an unbounded review scope, and approval evidence the CI container may discard. Before you grant approval, pull the last month of merged pull requests your reviewer commented on and label the ones developers later reverted or hotfixed. Then calculate the false-approve rate.
Frequently Asked Questions
Related Reading
- 10 Open Source AI Code Review Tools Tested on a 450K-File Monorepo [2026 Rankings]
- Best AI PR Automation Tools for Engineering Teams 2026
- Autonomous Code Review Platforms for Enterprise Teams
- 8 Best AI Coding Assistants by Job [Updated August 2026]
- How to Test AI Coding Assistants: 7 Enterprise Benchmarks
Written by

Paula Hingel
Paula writes about the patterns that make AI coding agents actually work — spec-driven development, multi-agent orchestration, and the context engineering layer most teams skip. Her guides draw on real build examples and focus on what changes when you move from a single AI assistant to a full agentic codebase.