A repository that requires one approval may no longer require a person to provide it. On September 1, 2026, GitHub introduced Copilot approvals that can count toward pull request merge requirements. The feature is in public preview and off by default. Enabling it changes who can satisfy an existing review requirement, even if the required approval count stays the same.
For repositories where a person must review every change, keep Copilot approvals from counting and verify the branch rules that enforce that decision. If you choose to delegate approval for a narrow class of changes, define that class explicitly and check what happens when a pull request also touches something outside it.
The rollout checks below are recommendations; we have not tested these settings in a Copilot tenant. For the wider deployment baseline, see securing coding agents.
Separate the assessment from the approval#
Copilot can say a pull request is ready without satisfying any merge requirement. Its review documentation distinguishes the assessment in the overview comment from a submitted approving review. Whether that review counts depends on administrator policy.
The September 18 review-interface update makes the distinction worth checking. The overview now tracks open, resolved, and previously missed findings across reviews. Those improvements are generally available; the approval feature remains a separate public preview. A cleaner overview or fewer open comments does not establish that a required human review occurred.
Write the intended policy in terms of the merge decision: "Copilot may advise on this repository, but its approval must not reduce the number of required human approvals." A record that only says "Copilot review enabled" leaves that decision unresolved.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Decide where an AI approval may count#
GitHub's configuration guide separates permission to submit an approval from permission to count it. At repository level, these are the two Auto-approval controls under Settings → Copilot → Code review. Enterprise policy can prohibit approvals or delegate to selected organizations; organization policy can disable counting, enable it, or delegate to repositories.
For a restricted rollout, the repository's File paths setting accepts up to 15 globs. Every changed file must match an allowed glob for the approval to count. Leaving the list blank permits all files.
Start with counting disabled wherever human review is mandatory. If an organization deliberately accepts AI approval for selected work, choose a narrowly owned directory and review what it contains. A directory named docs can still hold deployment instructions, executable examples, or security policy. Its name is not a risk assessment.
The following hypothetical pilot permits counting only for docs/copy/**. It is a proposed acceptance matrix derived from the documented all-files rule, not a report of tests we ran.
| Pilot pull request | Expected counting behavior | Administrator decision |
|---|---|---|
Only docs/copy/intro.md changes | Eligible if the other approval settings allow it | Confirm that this material is suitable for delegated approval. |
That file plus src/auth.ts changes | Ineligible under the path restriction | Keep the required human review for the complete change. |
Only .github/workflows/release.yml changes | Ineligible under the path restriction | Preserve review of deployment authority. |
| Path list is empty | All paths are eligible for counting | Treat this as expanded scope; use the counting control to disable it. |
Eligibility does not promise that Copilot will approve, or that the pull request can merge. Other requirements still need separate evaluation.
Keep the independent repository controls#
Review the target branch's required reviews, code-owner requirements, status checks, and bypass permissions. GitHub's branch protection documentation treats these as distinct controls and notes that administrators can bypass branch protection by default unless the relevant restriction is enabled. A review policy that works only for ordinary contributors is incomplete if the automation identity can bypass it.
Do not infer that a counting Copilot approval satisfies a particular code-owner requirement. Check the remaining requirements shown for the actual pull request. Likewise, increasing the total approval count does not by itself express a rule about which approvals must come from humans. Keep counting disabled when that distinction is essential, or enforce and verify the specific human requirement independently.
GitHub's Copilot review reference says new commits dismiss its approval. The automatic-review configuration separately offers review after new pushes. If it is not enabled, request another review explicitly.
Local tool permissions answer a different question. Allowing an agent to edit files or run tests does not define who can approve the resulting pull request. Keep the managed operation-permissions rollout and repository approval policy explicit in the same deployment decision.
Capture the review and the decision it supported#
For each pilot case, record the target branch, current head SHA, effective approval settings, changed paths, submitted reviews, and remaining merge requirements. Use a non-production repository and harmless edits. These checks validate the approval policy; they do not measure the model's ability to find defects.
This read-only example lists review records using an already authenticated GitHub CLI. Replace OWNER, REPO, and PULL_NUMBER. For private repositories, GitHub documents read-level Pull requests permission for supported fine-grained tokens. Keep the export in your approved evidence store.
Code source: GitHub's list-reviews endpoint, adapted for GitHub CLI.
gh api --method GET --paginate \
-H 'Accept: application/vnd.github+json' \
-H 'X-GitHub-Api-Version: 2026-03-10' \
'repos/OWNER/REPO/pulls/PULL_NUMBER/reviews?per_page=100' \
--jq '.[] | {id, reviewer: .user.login, state, commit_id, submitted_at}' \
> review-events.ndjson
The output contains a reviewer identity, state, commit SHA, and submission time for each review. Historical APPROVED rows can outlive the conditions under which they counted. Preserve dismissed records, compare the reviewed commit with the current head, and inspect GitHub's current requirements before deciding that an approval satisfies the policy.
Complete the pilot by adding a harmless commit after an approval. Confirm the dismissal and obtain a fresh review. Also check a mixed-file change and the counting-disabled case. Save the observed results beside the intended policy, including any case that could not be verified.
If the pilot allows counting where human review was intended, disable counting at the governing scope and inspect affected open pull requests. Recheck their current requirements before resuming merges; changing a setting is not evidence that every pending pull request now has the desired review state.
Frequently asked questions
- Does Copilot's approval assessment satisfy required reviews?
No. The assessment in the overview comment is advice. A submitted approving review can count only when the applicable administrator settings allow it to count toward merge requirements.
- What happens when a pull request includes a file outside the allowed paths?
GitHub documents that every changed file must match an allowed glob for the Copilot approval to count under that path restriction. An empty path list permits counting for all files; it does not disable counting.
- Does a new commit keep the previous Copilot approval?
GitHub says new commits dismiss the Copilot approval. Request another review and check the resulting state against the current pull request head and applicable merge requirements.
