GitHub lets Copilot code review approve pull requests in public preview

GitHub has moved Copilot code review closer to the merge gate. In a September 1 changelog post, the company said Copilot can now submit approving reviews on pull requests when administrators explicitly enable the capability. The feature is in public preview for Copilot Pro, Pro+, Max, Business, and Enterprise plans, and GitHub says the approval assessment will now appear in every Copilot review overview comment.

What changed for reviewers

The important shift is that Copilot is no longer limited to advisory comments in this workflow. GitHub says Copilot can sign off on a pull request in a way that counts toward a repository's required approvals rule, but only after admins turn on that behavior. The default remains conservative. Approval assessments appear automatically, while binding approvals require configuration at the enterprise, organization, or repository level.

Repository admins also get a narrower control. GitHub's documentation says teams can limit which file paths count toward merge requirements, with up to 15 globs supported. That gives platform teams a practical way to test the feature on lower risk areas such as documentation, generated fixtures, or internal tooling before allowing it near authentication, payments, or production infrastructure.

Why it matters

For engineering groups that already require reviews on every pull request, AI approvals could reduce queue time on routine changes. The tradeoff is governance. A Copilot approval can satisfy a rule, so teams need to decide whether the rule is meant to prove that another human has inspected the change, or whether it is meant to add an independent automated check that can clear well scoped work.

GitHub says approvals are dismissed if new commits are pushed after Copilot approves, matching the way human reviewer approvals are handled. That helps avoid stale approvals, but it does not answer the harder question of what Copilot is qualified to approve. CyberOGZ would treat the public preview as a policy feature first and a productivity feature second. The safest rollout is path based, auditable, and paired with required tests and security scans that do not depend on the same model judgment.

The next signal to watch is whether GitHub adds richer audit metadata around model choice, review settings, and approval reasoning. Without that, regulated teams may find the feature useful for triage but harder to defend as a formal control.

Sources

• github.blog
• docs.github.com

Cover photo by Bibek ghosh on Pexels, used under the Pexels License.