Copilot Code Review Can Approve Pull Requests. Four of Our Last 53 Would Qualify.

On 1 September 2026 GitHub shipped the ability for Copilot code review to submit an approving review that counts toward a repository's required-approvals rule. It is in public preview, it covers Copilot Pro, Pro+, Max, Business and Enterprise, and it is off by default. Enterprise admins can leave it off or delegate to organizations; organizations can turn it on everywhere, hand the choice to repositories, or scope it to named ones; repositories get a toggle and a path restriction.

The approval is the headline. The path restriction is the feature.

What the docs add to the announcement

The changelog covers the shape of the feature: approvals are off by default, every Copilot review carries an approval assessment that counts for nothing on its own, and a repository can restrict which file paths Copilot is allowed to approve. Two details that decide whether any of it ever fires are left to the documentation.

First, the approval is not a standalone switch — it is configured through a branch ruleset, alongside the rules you already run. Second, that path restriction is a list of file globs capped at fifteen patterns, and a Copilot approval counts toward merge requirements only when every changed file in the pull request matches one of them.

Not most files. Every file.

Approvals are dismissed when new commits land, the same way a teammate's approval is. Across the four documentation pages that describe Copilot code review, neither CODEOWNERS nor GitHub Enterprise Server is addressed at all — so if you require code owner review on a path, the docs do not yet tell you what a Copilot approval does there.

The glob rule is the whole feature

Here is the claim, and it is falsifiable in about ninety seconds: on a repository with any generated or cross-cutting files, almost no pull request will clear the every-file-matches bar, and the feature will sit enabled and idle.

We ran it on the repository behind this site. Of the last 53 merged pull requests, 4 had every changed file inside a two-pattern allowlist of the content and editorial directories. Thirty-two of the remaining 49 missed by exactly two files — the two generated llms text files that every content pull request regenerates and stages.

That is the shape of the problem. The pull requests were not sprawling; they were content changes plus two build artifacts riding along. A glob list written by looking at what people intend to change will miss what the build actually changes.

Run this against your own default branch before you argue with the number:

for n in $(gh pr list --state merged --limit 100 --json number --jq '.[].number'); do
  gh pr view $n --json files --jq '.files[].path' \
    | grep -vcE '^src/content/posts/|^editorial/'
done | sort -n | uniq -c

Swap the pattern for the globs you would actually write. The first row is the count of pull requests with zero files outside your list — the ones a Copilot approval could have carried. If that row is under a third of the total, your glob list is the thing to fix, not the review quality.

GitHub already had an opinion about this

The rulesets reference carries a rule that adds one required approval for unattributed Copilot pull requests — the ones Copilot opens under its own app identity rather than on behalf of a person. It also carries a rule requiring approval from someone other than the last person to push, and a code owner rule that any single code owner can satisfy.

So the platform now ships a control that adds a human when Copilot writes the change, and a control that removes one when Copilot reviews it. Nothing stops a repository from enabling both. These are different risks and it is reasonable for them to be separate settings, but neither the changelog nor the rulesets reference mentions the other, so nothing in the documentation prompts the person enabling one to think about the other.

What it does to your control narrative

If your change-management evidence leans on a framework, check what the framework actually says before you flip this on. NIST SP 800-218, the Secure Software Development Framework version 1.1 from February 2022, splits practice PW.7 into code review, defined as a person looking directly at the code, and code analysis, defined as tools finding issues either fully automatically or alongside a person. PW.7.1 puts the choice between them with the organization. The notional example under PW.7.2 that uses a static analysis tool still pairs it with a human reviewing the issues the tool reported.

A Copilot approval is code analysis in that vocabulary, and SSDF does not forbid it. But if your control description says every merge to the default branch received a peer review, enabling this changes what that sentence means without changing the sentence. Write the decision down first. It is the ordinary way an AI rollout stalls after the technology already works: the tool does its job, and nobody updates the process document the tool invalidated.

Adopt, wait, or ignore

Run the command. If fewer than a third of your merged pull requests come back with zero files outside your candidate globs, widen the list to cover the generated files that ride along — lockfiles, generated indexes, build artifacts — and measure again. Fifteen patterns is a real budget in a monorepo, and it is per repository, so a hundred-repository org is a hundred lists to maintain.

Leave the someone-other-than-the-last-pusher rule on regardless. Leave Copilot approvals off on any path that has a code owner until the documentation says what happens there. And treat the whole thing as what it is labelled: a public preview, subject to change, which is a poor foundation for a compliance control and a fine one for a low-risk path like generated documentation. The gap between a preview that works in a demo repository and a setting your auditors will read is the gap that swallows proofs of concept.

The cost of this feature is not the model's judgement. It is the configuration surface: three levels of inheritance, a ruleset, and a fifteen-entry path list per repository, every one of which has to be right before a single approval lands.