Can GitHub Copilot Approve a Pull Request?

Pull request reviews are an important part of a development workflow.

Traditionally, a pull request goes through something like this:

Developer
   |
   v
Pull Request
   |
   v
Code Review
   |
   v
Approval
   |
   v
Merge

GitHub Copilot can now participate in more of this process.

GitHub has introduced Copilot pull request approvals as a public preview feature. When the feature is enabled, Copilot can submit an approving review that can count toward a repository's required approval rules. Approval is disabled by default and can be controlled at the enterprise, organization, and repository levels.

That raises an obvious question:

Can Copilot actually approve a pull request?

Yes, when the required settings are enabled.

But there is an important difference between Copilot saying that a pull request appears ready for approval and Copilot actually submitting an Approve review.

Understanding that difference is important before changing your repository's merge rules.

How Copilot Code Review Normally Works

By default, Copilot reviews a pull request and leaves a comment-style review.

For example:

Pull Request
     |
     v
Copilot Review
     |
     +-- Bugs
     +-- Security concerns
     +-- Maintainability issues
     +-- Suggested changes
     |
     v
Developer reviews feedback

The default Copilot review does not count toward required pull request approvals.

GitHub's documentation states that Copilot normally leaves a Comment review rather than an Approve or Request changes review.

That behavior is important because simply requesting a Copilot review does not automatically satisfy your branch protection or ruleset approval requirements.

What Changed With Copilot Approvals?

GitHub added an approval assessment to Copilot code reviews.

The assessment tells you whether Copilot considers the pull request ready to approve.

For example, the review can effectively communicate:

Copilot Review

Issues found:
None

Approval assessment:
Ready to approve

However, this assessment by itself does not count as an approval.

GitHub explicitly distinguishes the assessment from an actual approving review.

The workflow can therefore look like this:

Copilot Reviews PR
       |
       v
Approval Assessment
       |
       +---- Not ready
       |       |
       |       v
       |    Fix issues
       |
       +---- Ready
               |
               v
       Approval enabled?
               |
          +----+----+
          |         |
         No        Yes
          |         |
          v         v
   No approval   Copilot
                 submits
                 approval

Copilot Approvals Are Off by Default

This is an important configuration detail.

GitHub does not automatically make every Copilot review count as an approval.

The approval capability must be enabled.

Administrators can control the behavior at different levels:

• Enterprise

• Organization

• Repository

At the enterprise level, administrators can allow organizations to decide or disable Copilot approvals.

At the organization level, administrators can enable approvals everywhere, allow repositories to decide, enable them for selected repositories, or disable them.

Repository administrators can then configure the feature where organizational policy permits it.

Where Can Copilot Approvals Count?

There are two related settings to understand.

One setting allows Copilot to submit an approval.

Another controls whether that approval counts toward the repository's merge requirements.

This distinction matters.

For example:

Allow Copilot to approve
        |
        v
Copilot can submit approval


Count Copilot approval
        |
        v
Approval can satisfy
required review rules

A repository can therefore have Copilot performing reviews without allowing those reviews to satisfy the required approval count.

GitHub provides separate configuration for these behaviors.

A Simple Example

Suppose a repository requires:

Required approvals: 2

Two human developers normally need to approve:

Developer A  -> Approve
Developer B  -> Approve

Now suppose Copilot approval is enabled and configured to count toward merge requirements.

The pull request could have:

Copilot      -> Approve
Developer A  -> Approve

If the repository's rules allow those approvals to satisfy the required count, the approval requirement could be met.

The important point is that this behavior depends on the repository and organization configuration.

It is not the default behavior.

Copilot Approval Is Different From Copilot Coding Agent

Another distinction is important.

GitHub has multiple Copilot capabilities that can interact with pull requests.

Copilot can:

• Review code

• Suggest changes

• Work on coding tasks

• Open or modify pull requests

• Provide an approval assessment

• Submit an approval when configured

These are related but different capabilities.

For example:

Copilot Coding Agent
        |
        v
Writes or changes code
        |
        v
Pull Request
        |
        v
Copilot Code Review
        |
        v
Review / Approval Assessment

The coding agent and code review capabilities should not be treated as the same thing.

What Happens When Code Changes After Approval?

Pull requests can change after a review.

Suppose Copilot approves:

Commit A
   |
   v
Copilot Approval

Then a developer pushes:

Commit B

The code has changed.

GitHub handles Copilot's approval like a review that can become stale.

When new commits are pushed after Copilot approves, the approval is dismissed, just as a human approval can be dismissed under the repository's review rules. A new Copilot review can then be requested.

The workflow becomes:

Commit A
   |
   v
Copilot Review
   |
   v
Approval
   |
   v
Commit B pushed
   |
   v
Previous approval dismissed
   |
   v
New review required

This is important for maintaining review integrity.

Otherwise, an approval could remain attached to code that was never actually reviewed.

Can Copilot Automatically Review Pull Requests?

Yes.

Copilot code review can be requested manually, but GitHub also supports automatic code reviews.

Automatic reviews can be configured to run:

• When a pull request is opened

• When a draft pull request becomes open

• When new commits are pushed

• While a pull request is still a draft

The exact triggers depend on the repository and organization configuration.

A workflow could therefore look like:

Developer opens PR
       |
       v
Automatic Copilot Review
       |
       v
Issues found?
    /       \
  Yes        No
   |          |
   v          v
Fix issues   Approval
             assessment

If approvals are enabled, the second path can continue to an actual approval.

Manual vs Automatic Review

Both approaches have practical uses.

Automatic review provides more consistent coverage, while manual review gives developers more control over when Copilot runs.

GitHub documents these review configuration options separately from the approval setting.

File Path Restrictions

Repository administrators can also restrict which pull requests Copilot approvals can count toward merge requirements.

GitHub allows file path patterns to be configured for this purpose.

For example, an organization might want Copilot approval to count only when all changed files match certain paths.

Conceptually:

Copilot Approval
       |
       v
Check Changed Files
       |
       +---- Allowed paths
       |        |
       |        v
       |     Approval can count
       |
       +---- Other paths
                |
                v
          Approval does not count

GitHub's repository configuration supports file glob patterns for controlling which pull requests are eligible for Copilot approvals to count toward merge requirements.

This can be useful when different parts of a repository have different review requirements.

Why File-Level Controls Matter

Not every pull request carries the same risk.

A pull request changing:

README.md

is different from one changing:

src/Authentication/
src/Payments/
infrastructure/
.github/workflows/

An organization may want different review requirements for different areas.

Path-based controls provide a way to narrow where Copilot approvals can contribute.

This does not remove the need to define appropriate human review requirements for sensitive code.

Copilot Review Effort Levels

Copilot code review also supports different review effort levels.

GitHub currently documents options including:

Lite
Balanced

Lite provides a more targeted review.

Balanced performs deeper analysis of areas such as complex logic, security-sensitive code, and cross-service changes. GitHub notes that Balanced can consume more AI credits and may use more GitHub Actions minutes.

This matters because an approval workflow should not be designed independently of the review configuration.

For example:

Low-risk repository
      |
      v
Standard review


Complex service
      |
      v
Deeper review

The appropriate configuration depends on the repository and the organization's requirements.

Copilot Approval Does Not Mean Code Is Automatically Safe

An approval is a review result.

It is not proof that the code contains no defects.

Automated review can miss things such as:

• Business requirements

• Incorrect product assumptions

• Missing operational considerations

• Subtle architecture problems

• Unexpected production behavior

• Requirements outside the repository

• Problems involving external systems

For example, Copilot may correctly understand:

if (user.IsActive)
{
    ProcessPayment(user);
}

but it may not know that a particular business rule requires an additional fraud check unless that context is available.

Code correctness and business correctness are not always the same thing.

Use Tests Alongside Copilot Review

A pull request should ideally have multiple signals.

For example:

Pull Request
     |
     +---- Copilot Review
     |
     +---- Unit Tests
     |
     +---- Integration Tests
     |
     +---- Security Checks
     |
     +---- Build
     |
     +---- Human Review

Copilot approval should not replace automated testing.

A successful review does not mean that the application has passed its runtime and integration requirements.

Human Review Still Has a Different Role

Human reviewers can evaluate context that is difficult to infer from code alone.

A human reviewer might ask:

Does this change match the product requirement?

Will this work with the existing architecture?

Does this introduce an operational problem?

Does the database migration work during deployment?

Does this change affect customers in an unexpected way?

These questions are different from simply identifying a coding mistake.

This is why teams should define what Copilot is expected to handle and what still requires human review.

A Practical Review Workflow

A team could use a workflow like this:

Developer creates PR
        |
        v
Automated tests
        |
        v
Copilot code review
        |
        v
Address findings
        |
        v
Push updated code
        |
        v
Copilot re-review
        |
        v
Human review
        |
        v
Merge

If Copilot approvals are enabled, the approval can be added at the appropriate point.

The exact process depends on the repository's rules and risk profile.

What Happens If a New Commit Is Added?

Suppose the original pull request contains:

Commit A
Commit B

Copilot reviews it and approves.

Then the developer adds:

Commit C

The pull request is now different.

The previous Copilot approval is dismissed, and the review can be requested again.

This is an important safety mechanism because approvals should correspond to the code being merged.

Copilot Reviews Can Also Be Re-Requested

Developers can manually request a new Copilot review.

This can be useful after:

• Fixing review comments

• Changing multiple files

• Updating security-sensitive code

• Changing behavior across services

• Applying several suggested changes

GitHub's documentation recommends re-reviewing after substantial changes so that new risks introduced by the changes can be checked.

What About Copilot-Generated Pull Requests?

Copilot can also create pull requests through its coding-agent capabilities.

That introduces another consideration.

A coding agent can modify code, but the resulting pull request still needs to go through the repository's review and merge controls.

GitHub's documentation states that Copilot cloud agent pull requests require human review before merging and that the cloud agent cannot itself approve or merge its pull request.

This creates an important distinction:

Copilot creates code
        |
        v
Pull Request
        |
        v
Copilot code review
        |
        v
Approval capability
        |
        v
Repository merge rules

Different Copilot capabilities have different permissions.

Do not assume that because Copilot can approve a reviewed pull request, the coding agent can approve and merge its own work.

Security-Sensitive Files Need More Care

Repositories often contain areas that deserve stricter review.

Examples include:

.github/workflows/
infrastructure/
authentication/
authorization/
payment/
database migrations

A pull request modifying a CI workflow can potentially affect the permissions and execution environment available to automation.

Similarly, changes to authentication or authorization can have a much larger impact than a normal formatting change.

For these areas, organizations may want additional human approval requirements even when Copilot approval is enabled.

Do Not Use Approval as the Only Gate

A production repository should generally have multiple protections.

For example:

Build
  |
  v
Tests
  |
  v
Security Checks
  |
  v
Copilot Review
  |
  v
Human Review
  |
  v
Required Checks
  |
  v
Merge

The exact gates should match the repository's risk and deployment process.

The important point is that Copilot approval is only one signal.

Common Mistakes

Assuming Copilot Approval Is Enabled Automatically

It is not.

Copilot approvals are off by default.

Confusing Approval Assessment With Approval

Copilot can indicate that it considers a pull request ready to approve without actually submitting an approval.

These are separate concepts.

Removing Human Review Everywhere

Automated review does not understand every business or architectural decision.

Ignoring New Commits

A previous approval should not be treated as approval of code that was added afterward.

Enabling Approval Without Reviewing Repository Rules

Check how required approvals, branch protections, rulesets, and status checks interact.

Applying the Same Policy to Every Repository

A documentation repository and a payment service may have very different review requirements.

A Practical Adoption Strategy

If your organization wants to evaluate Copilot approvals, start with a limited scope.

Step 1: Select Low-Risk Repositories

Choose repositories where the workflow can be evaluated safely.

Step 2: Enable Copilot Code Review

Start with normal review comments and approval assessments.

Step 3: Review the Results

Measure whether Copilot's findings are useful.

Step 4: Define Approval Rules

Decide where Copilot approvals should and should not count.

Step 5: Use Path Restrictions

If appropriate, restrict approval eligibility to suitable file paths.

Step 6: Keep Required Checks

Continue requiring builds, tests, and other important checks.

Step 7: Expand Carefully

Only after the workflow is understood should it be applied to additional repositories.

A Simple Policy Model

A practical organization could define different policies based on repository characteristics.

For example:

Internal low-risk repository
    |
    +-- Copilot review
    +-- Automated tests
    +-- Copilot approval allowed


Production service
    |
    +-- Copilot review
    +-- Automated tests
    +-- Security checks
    +-- Human approval required


Security-sensitive repository
    |
    +-- Copilot review
    +-- Automated tests
    +-- Security checks
    +-- Multiple human approvals

The exact policy should be based on the organization's risk model.

The important part is to avoid treating every repository identically.

Summary

GitHub Copilot can now do more than comment on pull requests.

With the appropriate configuration, Copilot can submit an approving review, and that approval can count toward a repository's required approval rules. The feature is currently in public preview and is disabled by default.

The workflow is roughly:

Pull Request
     |
     v
Copilot Review
     |
     v
Approval Assessment
     |
     v
Approval Enabled?
     |
     +---- No ----> Review only
     |
     +---- Yes
             |
             v
       Copilot Approval
             |
             v
     Repository Rules

There are still important safeguards. If new commits are pushed after Copilot approves, the approval is dismissed and a new review can be requested. Repository administrators can also control whether Copilot approvals count toward merge requirements and can restrict eligible file paths.

The practical approach is to treat Copilot approval as one part of the pull request process rather than the entire process.

Builds, automated tests, security checks, repository rules, and appropriate human review still have their own roles.

For teams experimenting with the feature, starting with a small number of lower-risk repositories makes it easier to understand how Copilot's reviews and approvals fit into the existing development workflow before expanding the configuration further.