GitHub Copilot Code Review Can Now Formally Approve PRs, With Approval Votes Counting Toward Merge Requirements

GitHub has expanded the permissions of Copilot code review: every review now includes an “approval readiness” assessment in its overview comment, while administrators can additionally allow Copilot to submit a formal Approve review. The assessment alone does not affect merge rules; Copilot’s vote counts toward the repository’s required number of approvals only when formal approvals are enabled. When new commits are added to a PR, previous approvals are dismissed just like human reviews, and another review must be requested.

This capability is disabled by default, with controls available at the enterprise, organization, and repository levels. Enterprises can disable it entirely or delegate the decision; organizations can enable it for selected repositories; and repository administrators can restrict the file paths that Copilot is allowed to approve. The feature is currently available in public preview for Copilot Pro, Pro+, Max, Business, and Enterprise plans. The technical change is not merely the addition of another summary: for the first time, model output can directly satisfy the required approvals condition in existing branch protection rules, making permission configuration part of software supply chain controls.

A recent large-scale study of GitHub events also shows that the closed loop of AI-authored, AI-reviewed code is not a fringe phenomenon. Researchers identified approximately 2.83 million agent-authored PRs, of which 248,641 received at least one AI review. Cross-product reviews accounted for about 1.6% of the identified agent-authored PRs. However, the data relies on attribution through product signatures, so the figures represent only a lower bound, and classifying comments does not establish that actual defects were found.

Teams should not treat Copilot approval as a direct substitute for security review. A safer approach is to initially limit it to low-risk paths, retain independent approval from humans or a different tool, and measure false negatives, false positives, and re-review behavior after new commits. Key questions going forward are whether GitHub will disclose its approval thresholds, publish model-version change logs, and provide stratified evaluations covering security vulnerabilities, generated code, and same-product closed-loop scenarios.