GitHub Copilot approvals turn code review into a merge-control decision

GitHub Copilot code review can now submit a real pull-request approval in public preview. When administrators enable the feature, that approval can count toward a repository’s required-approval rule—the point where an AI review stops being advisory and becomes part of the merge control.

The default remains off. GitHub exposes the setting through enterprise, organization, and repository controls, with optional file-path limits at repository level. That makes the rollout a policy decision for teams, not just another Copilot toggle.

What GitHub shipped on September 1

Every Copilot code review now includes an approval assessment in its overview comment. The assessment says whether Copilot considers the pull request ready to approve, but the assessment alone does not satisfy a merge requirement.

The separate approval capability is opt-in. Once enabled, Copilot can submit an approval that counts like a required review under the repository’s existing rules. The feature is available in public preview for Copilot Pro, Pro+, Max, Business, and Enterprise plans.

GitHub also preserves a familiar safeguard: if new commits arrive after Copilot approves, the approval is dismissed and a fresh review can be requested.

The control surface runs from enterprise to repository

Enterprise administrators can keep approvals disabled or let organizations decide. Organization administrators can enable the feature broadly, delegate the decision to repositories, select repositories, or disable it. Repository administrators get the final switch and can restrict the file paths Copilot is allowed to approve.

That hierarchy supports staged adoption. A team can first enable assessments everywhere, then allow approval submissions on low-risk repositories, and only later let those approvals satisfy merge requirements. Documentation, generated clients, translation files, and test fixtures are more defensible starting points than production, infrastructure, authentication, or payment code.

An independent implementation analysis highlights the same boundary: Copilot’s approval can become a real merge-gate input only after administrators explicitly enable the relevant controls. It also flags unanswered questions around CODEOWNERS behavior and Copilot-authored pull requests. Those details are not settled by GitHub’s announcement, so teams should test them in a scratch repository before changing protected-branch policy.

Why this changes software governance

The technical action is small—an automated actor submits an approval—but the policy consequence is larger. Required approvals often implement a four-eyes control. Adding Copilot to that reviewer set changes who can satisfy the rule and how teams must explain the decision later.

The preview status matters. GitHub does not provide approval-quality measurements in the announcement, and the source material does not answer every interaction with CODEOWNERS, merge queues, or agent-authored pull requests. Treat the feature as a bounded experiment with explicit logs, narrow paths, and a human approval requirement for sensitive changes.

A practical rollout sequence

1. Enable the assessment view and collect examples without allowing Copilot to approve.
2. If the signal is useful, enable approval submissions while keeping them outside merge requirements.
3. Limit approval-eligible paths and repositories; exclude security-sensitive and regulated code.
4. Test new-commit dismissal, CODEOWNERS, merge queues, and Copilot-authored pull requests.
5. Review cost and review frequency before allowing approvals to satisfy required-approval rules.

GitHub’s announcement establishes the capability; the next milestone is operational evidence from teams that can show where an AI approval is permitted, what it reviewed, and when a human remains mandatory.

Sources and methodology

• GitHub Changelog: Copilot code review can now approve pull requests
• Independent implementation analysis