Copilot Can Approve Pull Requests: Prove the Review Is Independent Before It Counts

Separate the Assessment From the Approval

GitHub announced the capability on September 1, 2026. Every Copilot code review now includes an approval assessment in its overview comment, but GitHub says that assessment alone does not count toward merge requirements. An administrator can separately allow Copilot to submit an approving review and allow that approval to satisfy a repository's required-approvals rule.

That distinction is the first test assertion. Capture the overview assessment, the submitted review state, and the branch or ruleset decision as three separate fields. If your evidence says only "Copilot was green," you cannot tell whether you observed advice, an approving review, or an approval that actually reduced the remaining requirement.

Use the decision questions in the AI pull request review checklist for the human review. Use the broader AI merge-readiness checklist to decide whether the test repository has enough rollback, test, security, and operational evidence. This fixture is narrower: it proves how one Copilot approval interacts with one concrete merge policy.

Build a Fixture With Two Independent Locks

Create a disposable repository, or a non-critical branch that cannot deploy to production. Protect the test branch with two required approvals and one required status check named independent-review. Configure that check under an identity or workflow boundary that the Copilot approval cannot satisfy. The two-approval count is a test design, not a GitHub default: it makes the remaining human approval visible after Copilot contributes one.

In the repository's Copilot code review settings, record both switches: Allow Copilot to approve pull requests and Allow Copilot approvals to count toward merge requirements. GitHub exposes them separately. The configuration documentation also allows up to 15 path globs, one per line. An approval counts under that path scope only when every changed file matches at least one configured glob; leaving the list blank permits all files.

Use exactly one glob for the exercise:

docs/**

Create a neutral base commit, then open each case from a fresh branch. Keep author, repository, target branch, ruleset, Copilot settings, and independent-check definition unchanged. Change only the path or event named by the case. This makes a failed result diagnosable instead of leaving you to guess whether two policy changes interacted.

Run the Four Pull Requests

For case A, do not complete the merge. First observe the state after Copilot acts but before a human approves or the independent check passes. The expected remainder is explicit: one human approval plus one required check. Then let the human approve and let the check pass only long enough to confirm the policy could become mergeable. Close the pull request without merging.

Case B is the scope trap. A docs-only pull request should exercise the allowed rule. A pull request containing src/fixture.ts should exercise the excluded rule, even when it also contains an allowed docs file. If Copilot's review comment looks favorable, that does not change the assertion: inspect whether the required-approval rule was actually satisfied. The product's overview assessment and its counted approval are different signals.

For case C, obtain the Copilot approval before pushing the second commit. GitHub's release note says a new commit dismisses Copilot approval just as it dismisses a human review, after which you can request a fresh Copilot review. Record the old review timestamp, the new commit SHA, the dismissal state, and the new review timestamp. If the old approval remains effective, stop rollout and retain the evidence rather than weakening the assertion.

Case D is the proof of independence. Make independent-review fail or do not report it. Let the allowed-path Copilot approval count and, if needed for your two-approval fixture, provide the human approval. The pull request must remain non-mergeable because the separate check is missing. If an administrator can bypass the test, record that bypass surface but do not use it to manufacture a pass.

Capture the State, Not a Green Screenshot

For every case, store the pull request URL, head SHA, changed paths, effective path globs, both Copilot switches, review states, required-approval remainder, independent-check state, mergeability, timestamp, and tester. A screenshot can supplement this record, but it cannot replace the head SHA or policy values. The post-approval commit case is otherwise easy to misread after the page refreshes.

Score each case with one sentence:

PASS when observed_mergeability == expected_mergeability
AND observed_copilot_effect == expected_copilot_effect
AND independent_review_can_still_block == true

Do not score the quality of Copilot's code comments in this activation test. That is a separate evaluation with different inputs and criteria. Here the input is policy state plus a controlled path or commit event; the output is whether approval counting, dismissal, and the independent block behave as documented.

Keep the Initial Scope Narrow and Reversible

Copilot approval is off by default and configurable at enterprise, organization, and repository levels. GitHub currently labels the capability public preview and subject to change. The September 1 release lists Copilot Pro, Pro+, Max, Business, and Enterprise plans for the preview. Treat those as dated availability facts, not as a promise about later packaging or behavior.

Start with repositories and paths where an incorrect approval cannot authorize a production release, change access control, rotate credentials, modify billing, alter database migrations, or weaken security policy. Promote one path only after all four cases pass. Keep high-risk paths outside the globs and require a named human owner or separately administered gate there.

Retest when a ruleset changes, the path list changes, the required-approval count changes, the independent check changes ownership, or GitHub changes the preview behavior. Also retest a mixed-path pull request; a broad directory reorganization can silently move files across the boundary that your first fixture proved.

The Activation Record Is the Real Deliverable

A safe configuration record says more than "Copilot approvals enabled." It names the repositories, target branches, exact allowed globs, excluded high-risk paths, required approval count, independent blocker, administrative owners, four fixture results, and the date of the last retest. It also states the rollback: disable counting first, then disable Copilot approvals if the review itself should stop.

The feature can reduce review friction without erasing accountability, but only if your merge policy keeps distinct evidence distinct. Let Copilot contribute where the path scope and fixture justify it. For changes whose consequence requires independent judgment, make the human or separate gate mandatory and prove it can still say no.