Updated 4 Sep 2026: Repairs the dead GitHub Docs source and tightens the governance details using GitHub's current documentation: allowing Copilot to submit Approve reviews and allowing those approvals to satisfy merge requirements are separate repository controls, with up to 15 path globs available for merge-counting scope.

Key details

  1. Announced September 1, 2026.
  2. Copilot approvals are in public preview.
  3. Every Copilot code review includes an approval assessment, which does not itself count toward merge requirements.
  4. Submitting an Approve review is off by default.
  5. Repositories can separately control whether Copilot may approve and whether its approvals count toward merge requirements.
  6. Repository admins can specify up to 15 file globs for approvals that count toward merge requirements.
  7. GitHub says every changed file must match the configured globs for the Copilot approval to count.
  8. Enterprise, organization and repository policies control enablement.
  9. A new commit dismisses Copilot's prior approval.

What builders should take away

  1. Start by enabling Copilot approval reviews without allowing them to count toward merge requirements; measure false approvals before granting merge authority.
  2. Use path globs to exclude security, infrastructure, deployment and other high-risk files from AI approvals that count.
  3. Review organization and enterprise policy inheritance so repository settings cannot accidentally widen a centrally intended restriction.
  4. Define an explicit re-review process after pushes, because new commits invalidate the previous Copilot approval.
  5. Keep human CODEOWNERS or required-review controls for paths where accountability or domain expertise matters more than review throughput.
  6. Audit the GitHub setting periodically while the feature is in public preview because controls and semantics may change.

What changed

GitHub announced September 1, 2026 that Copilot code review can submit approving pull-request reviews when administrators enable the capability. Every Copilot review includes an approval assessment, but the assessment alone does not count toward merge requirements. GitHub’s current repository documentation makes the governance split explicit: `Allow Copilot to approve pull requests` lets Copilot submit Approve reviews, while `Allow Copilot approvals to count toward merge requirements` separately controls whether those reviews can satisfy approval requirements. Repository admins can also enter up to 15 file globs; an approval counts toward merge requirements only when every changed file matches the allowed globs. Enterprise and organization policies can disable the feature, enable it broadly, select repositories or delegate the final decision downward.

Why it matters

This changes Copilot code review from an advisory comment stream into a potential merge-control participant, but it does not have to be all-or-nothing. A team can permit Copilot to express an approval without granting that approval merge authority, then separately decide where AI approvals can satisfy required-review rules. That separation is useful for staged adoption: repositories can collect evidence on AI review quality before allowing it to replace a human approval in bounded paths.

An approval assessment is not the same as an approving review

Every Copilot code review includes an assessment of whether the pull request looks ready to approve. By itself, that assessment is advisory and does not satisfy merge requirements. Copilot submits an actual Approve review only when the relevant approval setting is enabled.

Approval and merge authority are separate controls

GitHub’s current repository settings expose one control to let Copilot approve pull requests and another to let those approvals count toward merge requirements. That means teams can trial visible AI approvals without immediately treating the bot as a required-review substitute.

Path scope can bound which approvals count

Repository admins can provide up to 15 file globs for merge-counting. GitHub says Copilot’s approval counts toward merge requirements only when every changed file in the pull request matches one of those globs. That can keep infrastructure, security or other sensitive paths outside the AI approval boundary.

The policy surface is hierarchical

Enterprise administrators can keep approvals disabled or allow organizations to decide. Organizations can enable them everywhere, choose selected repositories, delegate to repository admins or disable them. Repository settings provide the final approval and path controls where higher-level policy permits them.

New commits invalidate the old approval

If commits are pushed after Copilot approves, GitHub dismisses the approval like a human review and a fresh review can be requested. Teams should still define whether a human must re-review high-risk changes even when Copilot returns another approval.

What to watch next

  • Whether GitHub publishes approval-quality measurements, audit events or templates for regulated teams.
  • How Copilot approvals interact in practice with CODEOWNERS, enterprise rulesets and merge queues.
  • Whether GitHub expands path controls beyond the current up-to-15-glob mechanism.
  • Whether the separate approve-versus-count controls change as the feature moves toward general availability.

Still unclear

  • The feature is public preview and GitHub provides no independent approval-quality measurement.
  • The value of path gating depends on repository structure; broad globs can still grant Copilot meaningful merge authority.
  • GitHub’s documentation has recently moved URLs, so source links and detailed settings should be rechecked during preview.

Sources

Direct reading behind this dossier.

4 sources
Configuring code review by GitHub Copilot
GitHub Docs primary documentation

Current configuration documentation for the separate approve/count controls, organization and enterprise policy, and up-to-15 file-glob restriction.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment