GitHub has moved Copilot code review from advisory feedback into the merge-control path. In a public preview released on September 1, administrators can authorize Copilot to submit an approving pull-request review, and that approval can satisfy a repository's required-approval rule. The feature is off by default and can be governed at enterprise, organization, and repository level, including path-based limits at the repository.
That is a more consequential change than another review-quality improvement. A required approval is part of the control system that decides whether code can merge. GitHub now lets an AI reviewer occupy that position, even while its own documentation still says Copilot can miss problems, can make mistakes, and should be supplemented with human review. The governance question is therefore no longer only whether Copilot gives useful feedback. It is whether an AI-generated approval should be allowed to count as evidence that a change is ready to merge.
Copilot can now satisfy a merge requirement
Every Copilot code review now includes an approval assessment in its overview comment. By itself, that assessment is informational and does not count toward merge requirements.
Administrators can go further. When approvals are enabled, Copilot can submit an approving review that counts toward the repository's required-approvals rule in the same way a teammate's approval would. GitHub says approvals are disabled by default.
The setting is hierarchical. At enterprise level, administrators can keep the feature disabled or allow selected organizations to use it. Organization owners can enable it everywhere, let repositories decide, enable it for selected repositories, or disable it. Repository administrators can then choose whether Copilot is allowed to approve and whether its approvals count toward merge requirements.
That hierarchy matters because it turns AI approval into an explicit policy choice rather than an incidental side effect of enabling Copilot code review.
Path scoping is the main safety boundary
Repository administrators can restrict which changed files are eligible for Copilot approvals that count toward merge requirements. GitHub supports up to 15 file globs. An approval only counts when every changed file in the pull request matches one of the configured globs.
This gives teams a practical way to separate lower-risk and higher-risk parts of a codebase. Generated documentation, low-risk configuration, or tightly scoped maintenance paths could be eligible for AI approval, while authentication, payments, infrastructure, security controls, or other critical areas remain outside the allowed set.
The important detail is that path scoping applies to whether the approval counts toward the merge rule. It should therefore be treated as a branch-governance control, not merely as a Copilot preference.
New commits invalidate the approval
GitHub also preserves review freshness. If new commits are pushed after Copilot approves a pull request, the approval is dismissed, just like a human review that becomes stale after the code changes. A fresh Copilot review must then be requested before another approval can count.
That behavior prevents one approval from becoming a permanent token attached to a moving pull request. It also means the relevant control is not "Copilot approved this PR at some point," but "Copilot approved the current reviewed state."
For organizations automating reviews after every push, this can become part of a continuous gate. But the more automated the loop becomes, the more important it is to separate throughput from assurance. A fast sequence of machine review, machine approval, and merge can satisfy a ruleset while still leaving the organization dependent on the quality and scope of the reviewer.
GitHub's own guidance creates an important tension
GitHub explicitly says Copilot is not guaranteed to spot all problems, may make mistakes, and that users should validate its feedback carefully and supplement it with human review.
At the same time, the new preview lets an administrator configure Copilot approval so that it satisfies the repository's required-approval rule.
Those two facts are not contradictory, but they are operationally significant. A branch rule that requires one approval is often used as a proxy for independent review. Once Copilot can provide that approval, the rule may still be technically satisfied while the underlying assurance model has changed.
This is the key Aipolix conclusion: teams should not treat an unchanged required-approval count as proof that their review process is unchanged. If an AI reviewer can satisfy the rule, the identity and independence of the reviewer become part of the governance design.
Treat Copilot as an automated reviewer principal
A safer enterprise model is to treat Copilot as a distinct automated reviewer principal with its own permitted scope.
That means defining where its approval may count, whether a human approval is still required for critical paths, how CODEOWNERS or branch rules interact with it, whether automatic re-review runs after every push, and what audit evidence is retained. Teams should also decide whether AI approval is allowed for changes created by another AI agent, because that can collapse authoring and review into a machine-only loop.
The product now supports a granular policy surface. Enterprises should use that granularity instead of enabling approval globally.
A practical release gate would distinguish at least three cases: Copilot may comment but cannot approve; Copilot may approve but its approval does not satisfy merge requirements; or Copilot approval may count toward merge requirements within explicitly allowed repositories and paths. High-risk repositories can then require a separate human or rules-based control in addition to Copilot.
Preview status matters
Copilot approvals are still in public preview and GitHub says the feature is subject to change. That status is important for policy and control design. Teams should avoid building irreversible governance assumptions around a preview behavior without monitoring future changes.
The release is nevertheless a meaningful shift. GitHub has moved Copilot from advising a code-review decision to potentially participating in the formal decision that allows code to merge. For engineering governance, the right question is not whether AI can approve a pull request. It is under which repositories, paths, identities, and independent-review requirements that approval should be allowed to carry merge authority.