Copilot can now approve pull requests. Give it narrow merge authority

GitHub Copilot can now decide that a pull request is ready and, when administrators allow it, submit an approval that counts toward a protected branch's required-review rule. The capability entered public preview on September 1, 2026, for Copilot Pro, Pro+, Max, Business, and Enterprise plans.

That turns an AI review from advice into possible merge authority. This article separates the assessment that every Copilot review can show from the approval that branch protection can count. It then explains where to limit that authority and how to test the full approval, change, and re-review cycle.

What changed when Copilot gained approval authority?

Every Copilot code review now includes an approval assessment in its overview comment. GitHub describes this as Copilot's judgment about whether a pull request is ready to approve. The assessment is visible information; by itself, it does not satisfy a merge requirement.

A submitted approval is different. GitHub says administrators can enable Copilot to leave an Approve review, and that review can count toward the repository's required-approvals rule. Approvals are off by default. The feature can be controlled at enterprise, organization, and repository levels, while repository administrators can choose the file paths where Copilot is allowed to approve.

That distinction matters because a team can observe Copilot's assessment without changing branch protection. Enabling approvals changes the effect of the review. If one approval is enough to satisfy the repository's rule, a Copilot approval may become the event that clears that requirement.

GitHub still evaluates other merge requirements separately. Required status checks, code-owner requirements, merge queues, deployment rules, and any remaining human approvals keep their own behavior. Copilot approval does not make them pass.

Why should assessment and authority have different scopes?

An assessment has low direct authority. It can help a human reviewer notice that Copilot found no blocking concern, while the reviewer remains responsible for the merge decision. Teams can compare those assessments with test outcomes and human findings before deciding whether Copilot's judgment is dependable for a particular class of change.

An approval has a stronger operational effect because branch protection can count it. The relevant question is not whether Copilot sometimes writes useful reviews. It is whether a missed problem in an allowed path can clear a required gate without another accountable reviewer catching it.

GitHub has not supplied independent evidence that a Copilot approval is equivalent to a qualified human review for every language, architecture, or risk class. Public preview availability also does not establish that equivalence. BaristaLabs therefore recommends a wider scope for visible assessments and a much narrower initial scope for approvals that count.

Which paths are reasonable for a first approval pilot?

Start with paths where the consequences of an incorrect approval are bounded and where independent checks already enforce the important properties. Documentation, non-executable examples, or generated reference material may be candidates when they cannot alter runtime behavior, access, billing, customer data, or deployment configuration.

The file extension alone is not enough. A Markdown file can drive a documentation build, configure an agent, define a workflow, or carry product terms. A generated file can still enter a release artifact. Classify the path by what a merge can change, not by how harmless its name looks.

Keep executable code, authentication, authorization, payments, secrets handling, infrastructure, deployment workflows, dependency manifests, migrations, and AI instruction files outside the first approval scope. This is BaristaLabs guidance rather than a GitHub requirement. These paths either carry larger consequences or can change the tests, runtime, dependencies, and instructions on which automated review relies.

The existing merge controls should remain independent. A documentation-only pilot may still require successful link, build, and policy checks. If the repository needs a code owner for legal copy or security guidance, Copilot approval should not silently remove that requirement.

What happens after the approved pull request changes?

GitHub says a new commit dismisses Copilot's approval just as it dismisses a human approval under the feature's behavior. A fresh Copilot review can then be requested. This prevents an old approval from remaining attached to a changed diff, but only the observed pull-request state can show that the intended cycle worked.

Re-review is a separate setting. GitHub's documentation says Copilot does not automatically re-review every push unless automatic review has been configured to review new pushes. A team can therefore have stale approval dismissal working correctly while no replacement review appears automatically.

Test both events. After Copilot approves a bounded pull request, push a harmless change inside the allowed path and confirm that the approval no longer counts. Then confirm whether a new review is requested automatically or must be requested manually, according to the repository's chosen policy. Finally, verify that only a current approval satisfies the requirement.

Do not test only the happy path. Add a controlled change outside the allowed approval paths and confirm that Copilot cannot supply a counting approval for that diff. Also make one test fail and confirm that the approval does not make the pull request mergeable while the required status check remains blocked.

How should a team record the decision?

Record the control at the same level where it is administered. Name the enterprise and organization policy, repository, protected branch or ruleset, required approval count, paths where Copilot approval may count, excluded paths, re-review behavior, and owner. Link that record to the pull requests used for the initial test.

Preserve the evidence that matters after the setting changes: the assessment, submitted review state, changed commit SHA, stale-approval dismissal, replacement review, required checks, and final mergeability state. A screenshot of an enabled setting cannot show whether a newer commit invalidated the approval or whether another merge requirement remained active.

Review the path list when the repository changes shape. A directory that once held static documentation may later gain executable examples, publishing scripts, generated configuration, or agent instructions. The approval boundary should follow those consequences rather than remain frozen around an old pathname.

The review inputs deserve separate attention. GitHub documents that Copilot code review reads supported custom instructions and skills from the pull request's head branch. Our head-branch instruction guide explains why those files need explicit ownership. Do not put the files that shape the reviewer inside a low-friction approval scope.

Enable a small authority boundary, not an account-wide shortcut

Leave Copilot approvals off where the team has not classified change consequences or preserved independent controls. Where a pilot is justified, allow a small path set, require the checks that validate that content, and exercise one new-commit cycle before letting the approval affect routine merges.

Copilot's new assessment can be useful even when approval authority stays disabled. It gives teams evidence to compare with human review and test results without changing who can clear branch protection. Authority can follow later, after the repository has shown where that judgment is sufficiently bounded.

BaristaLabs helps engineering teams connect AI-assisted review to repository controls through process automation. If you are deciding whether one review bot should satisfy a merge rule, scope one approval pilot around a defined path, independent checks, and a recorded re-review test.

Sources

• GitHub Changelog: “Copilot code review can now approve pull requests”, September 1, 2026.
• GitHub Docs: “Using GitHub Copilot code review”, accessed September 5, 2026.
• GitHub Docs: “About protected branches”, accessed September 5, 2026.