GitHub let a Copilot approval count toward required reviews. Read the number first.

On October 28, GitHub made Copilot pull-request approvals generally available. Once an admin turns them on, Copilot can approve a pull request, and that approval counts toward the reviews the repository requires. The change this week is the number on the pull request: it can go up without a person.

This is an illustrative reading of GitHub’s changelog. The GitHub sentences add no facts beyond that note.

What GitHub changed

The changelog is dated October 28, 2026. Approvals and the Max review effort are available on Copilot Pro, Pro+, Max, Business, and Enterprise plans. The plan named Max is not the review effort. Approvals had been in public preview and are now generally available. The Max review effort is in public preview.

Copilot code review acts as a reviewer and as an approver. Every review includes an approval assessment in the pull request overview comment, saying whether Copilot considers the pull request ready to merge. GitHub states the rule in one sentence: “When approvals are turned on, Copilot can approve the pull request, and that approval counts toward your repository’s required approvals.”

If new commits are pushed after Copilot approves, GitHub says the approval is dismissed, and someone can request a new review. Approvals are off by default. Admins can turn them on at the enterprise, organization, or repository level. A repository admin can choose which file paths Copilot is allowed to approve.

Max sits beside the Lite and Balanced efforts. GitHub says it runs several review agents across models from different providers, then an aggregation agent reconciles their findings, resolves disagreements, and checks accuracy before one review is posted. GitHub says Max takes longer and uses more AI credits than Lite or Balanced. The note gives no amounts, and no error rate for Max or for approvals. Pairing Max with approvals where a missed issue costs the most is GitHub’s suggestion, not a measured rate.

A count is not a signature

A rule that requires an approval was one way to keep a person on a change. After this release, the same rule can count Copilot on the paths an admin allows. The integer does not say which happened.

of1.ai keeps a named person on a move that cannot be taken back. The method also requires human review for listed moves, including safety, money, rights, employment, and reputation. The method also requires a person for high-severity dissent, and for low-provenance evidence in a high-consequence claim.

GitHub’s examples of riskier pull requests are a change to authentication logic, and a change to a shared library several services depend on. The changelog gives no error rate for counting Copilot toward the required approvals on either one.

The method does not treat “The model answered” as evidence lineage. An approval with no record of what was checked, and by whom, is only a count.

GitHub calls Max’s review agents independent of one another. The method’s source-independence pass records which sources were examined and whether one depends on another. The changelog describes several models and then one combined review, not a second artifact. It does not say whether a disagreement between the agents is still on the page after that review is posted. That visibility is unknown. Do not fill it with a rate.

A path rule

Write these four lines before an admin turns approvals on. They apply the setting GitHub described. They are not a result from a repository.

1. Paths Copilot may approve. Name them. If you cannot, leave approvals off. GitHub says a repository admin can limit the paths.
2. Paths a named person still signs. Name the person. Start with authentication, shared libraries, and anything that cannot be taken back. If one of those stays on Copilot’s list, write why beside the path.
3. What the number means. Copilot’s approval increments the required-approval count on the paths in line 1. Max is still one reading of that diff after the models have been reconciled.
4. What turns the setting off. A usable form: a named reviewer finds a merged change, on an allowed path, that should not have merged. Approvals for that path go off until these lines are rewritten. GitHub does not report how often that happens.

One illustration

A repository requires one approval. Approvals are off. An admin turns them on and limits Copilot to documentation paths. A documentation change can merge on Copilot’s approval. A change to authentication stays outside that list, so the required approval is still a person, until someone widens the paths.

The changelog does not publish the path-filter syntax, and it does not call documentation safe. This shows the control the note describes. It is not a test of that control. On the paths you allow, how often does Copilot approve a change the named reviewer would have blocked? The October 28 note does not say.

What to do this week

• Check enterprise, organization, and repository settings. GitHub says approvals stay off until an admin turns them on.
• If they are on, write the four lines where the admins who can widen the path list will see them.
• Open one pull request Copilot has reviewed. Say whether its approval count is a person, Copilot, or something you cannot tell.
• If Max is on, treat the posted review as one reading. This note does not say the disagreements remain visible.

If you want Ask, Map, Move run live with Utlyze on that decision, that is a consult: $400 an hour, in 5-hour blocks. You leave with the map and a first move you can undo.