GitHub Copilot Code Review Can Now Approve Pull Requests, Off by Default
GitHub Copilot's automated code review can now submit approvals that count toward merge requirements, but the capability ships disabled by default and requires an administrator to opt in at the enterprise, organization, or repository level.
Overview
GitHub has given Copilot’s automated code review a new power: the ability to actually approve a pull request, not just leave comments on it. According to GitHub, “Copilot now tells you when a pull request is ready to approve, and admins can authorize it to sign off on approval.” The feature, announced September 1, 2026, ships off by default and must be turned on by an administrator at the enterprise, organization, or repository level.
What We Know
Every Copilot code review now surfaces an “approval assessment” inside its overview comment. GitHub said the assessment “signals whether Copilot considers the pull request ready to approve, giving you an at-a-glance read on its judgment alongside its detailed comments,” according to GitHub.
That assessment alone carries no authority. “An approval assessment alone does not count toward merge requirements. Copilot’s determination is surfaced so you can decide how to act on it,” GitHub said in the same changelog post. Actual merge-gating power only comes into play when an administrator separately turns the feature on: “By default, Copilot will not approve pull requests. When enabled, Copilot can submit an approval that counts toward the repository’s required-approvals rule,” according to GitHub. If a contributor pushes new commits after Copilot approves, that approval is dismissed automatically, “just like a human reviewer’s,” and a fresh review has to be requested from Copilot to get a new approval.
Control over the feature is layered across three tiers. At the enterprise level, admins can leave approvals off for the whole enterprise or let individual organizations decide. At the organization level, admins can turn approvals on org-wide, let repository admins decide for themselves, enable the feature for specific repositories, or keep it off org-wide. At the repository level, admins can turn approvals on or off and choose which file paths Copilot is allowed to approve, according to GitHub.
GitHub’s documentation lays out the underlying settings in more detail. At the repository level, an admin toggles “Allow Copilot to approve pull requests” to let Copilot submit approving reviews at all, and separately toggles “Allow Copilot approvals to count toward merge requirements” so those approvals can satisfy a repository’s required-approvals rule, per GitHub’s documentation. Repositories can also scope the feature to part of a codebase: the file-path setting accepts “one file glob per line,” counting an approval toward merge requirements only when every changed file in the pull request matches one of the globs, with “up to 15 globs” supported.
At the enterprise tier specifically, the default is to block the capability outright. GitHub’s documentation lists “Disabled everywhere” as an enterprise-wide option for the approval policy and states, “This is the default.” The capability is a public preview feature available to Copilot Pro, Pro+, Max, Business, and Enterprise plans, according to GitHub, and its documentation separately notes, at each of the three configuration tiers, that “Copilot approvals are in public preview and subject to change.”
Background
The approval feature arrives five days after GitHub widened what Copilot code review could handle in the first place. On August 27, 2026, GitHub removed a longstanding size ceiling on reviews: Copilot code review “previously had a 300 file or 20,000 lines of code limit on the size of a pull request it could review,” a restriction GitHub said “no longer applies,” according to GitHub. That same update extended automated review to pull requests authored by bots, including GitHub’s own Copilot cloud agent, which previously received only “a limited experience” when reviewed automatically.
What We Don’t Know
GitHub has not said when, or whether, the approval capability will move from public preview to general availability, nor has it published figures on how many organizations have turned it on since the September 1 rollout. The changelog and documentation also do not describe the technical basis for Copilot’s approval judgment or how it differs from the model behavior behind Copilot’s existing review comments.
Analysis
The distinction GitHub draws between an “approval assessment” and a submitted approval amounts to a deliberate two-step design. Every Copilot review now renders a visible judgment on whether a pull request looks mergeable, but that judgment carries no procedural weight unless an administrator has explicitly granted Copilot the authority to make it count — and even then, only within whatever enterprise, organization, repository, and file-path boundaries that administrator has set. The layered opt-in, paired with the default-off enterprise policy and the file-path glob restriction, suggests GitHub is treating merge-gating authority as a materially different threshold than review commentary, even as both now come from the same automated system.