Until this month, a Copilot code review was advice. It left a Comment review, never an Approve or Request changes, and GitHub's own documentation was explicit that Copilot reviews did not count toward required approvals. You could ignore it, act on it, or argue with it, but it never moved the merge button.
On 1 September 2026 that changed. Copilot code review now includes an approval assessment in every review, and administrators can authorise Copilot to submit an approving review that counts toward the repository's required-approvals rule. Ten days later GitHub followed up with auto-resolution of Copilot's own comments, shell-tool execution during reviews, and an ensemble of agents at the Lite effort level.
This is the moment where AI code review stops being a suggestion layer and becomes part of the control plane. That deserves more scrutiny than "turn it on and see". This article covers what changed, exactly how the controls compose across enterprise, organisation, and repository, what GitHub has not documented yet, and a rollout pattern that lets you benefit without quietly weakening branch protection.
If you want the wider landscape of Copilot review surfaces, my earlier definitive guide to code reviews with Copilot still applies. This post is narrowly about the approval capability and the governance around it.
Evidence boundary: Copilot approvals are a public preview and GitHub's docs say they are "subject to change". Everything below about product behaviour is grounded in the 1 and 11 September 2026 changelog entries and GitHub Docs as of 13 September 2026.
Three changelog entries in two weeks matter here.
27 August 2026. The 300 file / 20,000 line limit on Copilot code review no longer applies, and reviewers gained resolution reasons (Addressed, Won't fix, Incorrect) on Copilot comments.
1 September 2026. Two related things shipped in public preview for Copilot Pro, Pro+, Max, Business, and Enterprise:
11 September 2026. Copilot now resolves its own review comments during a re-review when a later commit addresses them, writes a generated commit message when you apply a Copilot suggestion, runs "the full set of shell tools from the Copilot SDK" behind the Copilot agent firewall to validate what it reviews, and uses an ensemble of agents at the Lite effort level. GitHub reports the ensemble increased addressed comments per review by 47% for high severity findings, 31% for medium, and 11% for low, while reducing review cost by about 8%.
Read together, the story is clear. The reviewer got more capable (it can build and run tests), more efficient (ensemble at Lite), and, optionally, authoritative (it can approve). The first two are uncontroversial. The third changes what your branch protection means.
This is where most of the value of this article lives, because the changelog summarises the controls and the docs spread them across three pages. Here is the full chain as documented in Configuring code review by GitHub Copilot.
Path: enterprise AI controls > Available Agents > Copilot code review, then Allow Copilot to approve pull requests.
| Option | Effect |
|---|---|
| Disabled everywhere | Default. No organisation can enable approvals. |
| Let organizations decide | Delegates to organisation settings. |
| Enable for selected organizations | Allow-list specific organisations. |
Path: organisation Settings > Copilot > Code review > Approvals > Count Copilot approvals toward merge requirements.
| Option | Effect |
|---|---|
| Enabled everywhere | Every repository counts Copilot approvals. |
| Let repositories decide | Delegates to repository settings. |
| Enable for selected repositories | Allow-list specific repositories. |
| Disabled everywhere | No repository counts Copilot approvals. |
Path: repository Settings > Copilot > Code review > Auto-approval.
| Setting | What it does |
|---|---|
| Allow Copilot to approve pull requests | Lets Copilot submit an Approve review at all. |
| Allow Copilot approvals to count toward merge requirements | Lets that approval satisfy the ruleset's required-approvals count. |
| File paths | Optional. One glob per line, up to 15. The approval counts only when every changed file in the pull request matches at least one glob. Blank means all files. |
The two-toggle design at repository level is the detail to internalise. You can allow Copilot to post an Approve review (useful signal in the timeline) without letting that review satisfy branch protection. The second toggle is the one that changes merge semantics.
Approvals are not configured in rulesets. Automatic review is. The ruleset rule is Automatically request Copilot code review, with sub-options Review new pushes and Review draft pull requests. In the REST rulesets API this is rule type copilot_code_review with parameters review_on_push and review_draft_pull_requests (REST API: repository rules).
That separation has a practical consequence for the 11 September auto-resolution feature: Copilot resolves its comments during a re-review. If your ruleset does not enable Review new pushes, a re-review only happens when someone requests it, so comments will not auto-resolve on their own.
Putting the chain together, a Copilot approval satisfies your required-approvals rule only when all of these are true:
enterprise policy allows the org
AND org policy allows the repo
AND repo: "Allow Copilot to approve pull requests" = on
AND repo: "Allow Copilot approvals to count toward merge requirements" = on
AND (file paths blank OR every changed file matches a configured glob)
AND Copilot's assessment is "ready to approve"
AND no commit was pushed after the approval
Any false in that chain and you are back to the pre-September behaviour: a review with an assessment that a human reads and acts on.
| Aspect | Before 1 Sep 2026 | Now (public preview) |
|---|---|---|
| Review type Copilot can leave | Comment only | Comment, or Approve when enabled |
| Effect on required approvals | None | Counts when enabled at every level |
| Readiness signal | Implicit in comment tone | Explicit approval assessment in every overview comment |
| Scope control | Repository on/off for reviews | Repository-level path globs for counting approvals |
| Comment lifecycle | Humans resolve threads | Copilot resolves its own threads on re-review when addressed |
| Validation during review | Static read of the diff | Shell tools inside the agent firewall (build, test, scripts) |
| Size limits | 300 files / 20k lines | Removed |
| Lite effort | Single pass | Ensemble of agents |
| Default effort (from 28 Sep 2026) | Lite | Balanced |
That last row is a cost item you should not miss. GitHub's 28 August billing changelog states that a review effort value of Default will use Balanced from 28 September 2026. According to the Copilot code review concept page, a Lite review typically consumes an estimated $0.05 to $1 of AI credits and a Balanced review $0.25 to $5, excluding GitHub Actions minutes. If you never explicitly chose Lite, your per-review cost ceiling rises fivefold in two weeks. Select Lite explicitly if that is what you want.
Required approvals are not a productivity feature. They are a control that auditors, security teams, and incident reviewers rely on. Letting a model satisfy that control is a policy decision, not a settings tweak. Three angles matter.
Separation of duties. Copilot can now be on both sides of a pull request: author (via Copilot cloud agent) and reviewer (via Copilot code review). GitHub already has a ruleset rule, Require an additional approval for unattributed Copilot pull requests (public preview, enabled by default), that adds one approval when Copilot opens a PR with no human attribution. The documentation for that rule and the documentation for Copilot approvals do not reference each other, so whether a Copilot approval can satisfy the extra approval on a Copilot-authored PR is not stated. Assume nothing; test it in your sandbox before relying on it.
Prompt injection becomes merge-relevant. A reviewer that only comments is a low-value target for content injected into a diff, a commit message, or a linked issue. A reviewer whose approval unblocks merge is a higher-value target. GitHub's agent firewall and read-only review contexts reduce that surface, but the correct mitigation is structural: keep a human approval on paths where a bad merge is expensive.
Metrics drift. Auto-resolution changes what "open review comments" means in your dashboards. A thread resolved by Copilot after a fix commit is a good outcome, but it is now indistinguishable in a naive count from a thread a human resolved. If you report on review health, tag the resolver.
The file paths control is the feature that turns "should an AI approve?" from a yes/no argument into an engineering decision. Here is a starting configuration for a repository where Copilot's approval is allowed to count only for low-blast-radius change classes.
Import this via Settings > Rules > Rulesets > Import a ruleset, or with the REST API. A copy lives in the article's code folder.
{
"name": "main: reviewed merges",
"target": "branch",
"enforcement": "active",
"conditions": {
"ref_name": {
"include": ["~DEFAULT_BRANCH"],
"exclude": []
}
},
"rules": [
{ "type": "deletion" },
{ "type": "non_fast_forward" },
{
"type": "pull_request",
"parameters": {
"required_approving_review_count": 1,
"dismiss_stale_reviews_on_push": true,
"require_code_owner_review": true,
"require_last_push_approval": true,
"required_review_thread_resolution": true,
"allowed_merge_methods": ["squash"]
}
},
{
"type": "copilot_code_review",
"parameters": {
"review_on_push": true,
"review_draft_pull_requests": false
}
}
]
}
To create it from the terminal:
gh api "repos/$env:OWNER/$env:REPO/rulesets" --method POST --input ./code/main-branch-ruleset.json
gh api uses your existing gh auth login token. Creating repository rulesets requires repository admin permissions. Do not put a personal access token in the command or in the file.
* @acme/platform-reviewers
/infra/** @acme/platform-security
/src/auth/** @acme/identity-team
/.github/workflows/** @acme/platform-security
Because the ruleset requires code owner review, any PR touching these paths needs a designated human owner regardless of what Copilot does. The interaction between Copilot approvals and code owner reviews is not documented, and the safe assumption is that Copilot is not a code owner.
In Settings > Copilot > Code review:
docs/**
*.md
CHANGELOG.md
With this configuration, a documentation-only PR can be merged with Copilot's approval plus a passing CODEOWNERS check from @acme/platform-reviewers if that team is also required for *. If you want docs PRs to merge on Copilot's approval alone, narrow the * CODEOWNERS entry so it does not cover docs/** and Markdown files. That is a deliberate choice; make it in a PR that the security team reviews.
Set the enterprise policy to Enable for selected organizations and the organisation policy to Enable for selected repositories. Add only the pilot repository. Allow-lists at both levels mean a repository admin cannot opt in without a platform-level decision, which is exactly the property you want for a control that affects merge gating.
Do not trust a settings page. Prove the behaviour with two pull requests in a non-production repository that has the configuration above.
PR A: in scope. Change only docs/getting-started.md. Let the automatic review run. Expect an overview comment containing an approval assessment. If Copilot judges it ready, expect an Approve review from copilot-pull-request-reviewer[bot] and the required-approvals check to turn green.
PR B: mixed scope. Change docs/getting-started.md and src/auth/session.ts. Expect the review, expect the assessment, and expect the approval not to count, because not every changed file matches a glob. Expect the code owner requirement for /src/auth/** to remain unsatisfied.
PR A, second push. Push a trivial follow-up commit to PR A. Expect Copilot's approval to be dismissed. With Review new pushes on, expect a re-review and, if the diff still passes, a fresh approval.
Inspect the review state from the terminal:
gh pr view 42 --json reviews --jq '.reviews[] | {author: .author.login, state: .state, submittedAt: .submittedAt}'
Expected shape of the output for PR A after the automatic review:
{
"author": "copilot-pull-request-reviewer[bot]",
"state": "APPROVED",
"submittedAt": "2026-09-14T09:12:41Z"
}
Then confirm merge-readiness from the same data source your automation would use:
gh pr view 42 --json mergeStateStatus,reviewDecision --jq '{mergeStateStatus, reviewDecision}'
reviewDecision should remain REVIEW_REQUIRED for both PRs until @acme/platform-reviewers approves PR A; after that, PR A can become APPROVED if Copilot satisfies the required-approval and last-push rules, while PR B remains REVIEW_REQUIRED. Record the undocumented interactions rather than assuming them.
A small PowerShell helper that runs these checks for a list of PR numbers is included in the code folder.
Being precise about the gaps is more useful than pretending they do not exist. As of 13 September 2026:
| Question | Status |
|---|---|
| Does a Copilot approval satisfy Require approval of the most recent reviewable push ? | Not documented. The rule requires approval "by someone other than the person who pushed it". A fresh Copilot approval after the last push plausibly qualifies, but no docs page says so. |
| Does a Copilot approval satisfy Require review from Code Owners ? | Not documented. Copilot is not a CODEOWNERS entity. Assume no. |
| Does a Copilot approval trigger auto-merge ? | Not documented. If the approval satisfies all required rules, standard auto-merge logic would presumably proceed. Test it. |
| Can a Copilot approval satisfy the extra approval from Require an additional approval for unattributed Copilot pull requests ? | Not documented. |
| Exact wording of approval assessment outcomes | Not documented beyond "whether Copilot considers the pull request ready to approve". |
| REST or GraphQL surface for the approval settings | None found in the rulesets API or the Copilot REST API. Configuration is UI-only for now. |
| Audit log | Settings changes surface as copilot.code_review_repository_settings_updated andcopilot.code_review_organization_settings_updated . No approval-specific event is documented. |
| GitHub Enterprise Server | The docs are versioned for GitHub.com and Enterprise Cloud only. No GHES availability is stated. |
package.json or Gemfile.lock, log files, or SVGs. Be cautious about letting an approval count on lockfile-only PRs when the reviewer did not read the lockfile.docs/** and Markdown, keep a human code owner on anything else. Approvals count, humans are freed from reviewing typo fixes.required_approving_review_count at 2 and let Copilot count as one. A human still signs every merge, and the human reviewer starts from Copilot's findings./infra/** under a security code owner so anything material still needs a person.
This is opinion, clearly labelled.
Letting Copilot's approval count is defensible only when three things hold: the change class is genuinely low blast radius, the path allow-list is narrow enough that generated files and incidental edits do not defeat it, and a human still owns the merge decision on anything security-relevant through CODEOWNERS. Under those conditions the feature removes real toil. Outside them, it is a way to make branch protection look intact while removing the person who was providing the protection.
The approval assessment, on the other hand, should be on everywhere. It costs nothing extra, it is a better signal than scanning fifteen comments to infer whether the reviewer was broadly happy, and it trains teams to read Copilot's judgement critically before anyone proposes letting it count.
The 11 September changes are the more important technical shift. A reviewer that can run the build and the tests inside a firewalled environment is a different class of tool from one that reads a diff. That is what will eventually make the approval question less fraught. Until GitHub documents the CODEOWNERS and last-push interactions, and exposes the settings through an API you can enforce with policy-as-code, treat counting approvals as a pilot, not a platform default.
Copilot earning the right to approve is a reasonable direction. Whether it has earned it in your repository is a question only your evidence can answer.
Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn
Date: 13-09-2026