When the Reviewer Closes Its Own Comments: Copilot Code Review’s 2026 Additions, the June 1 Billing Change, and the Upgrade That Went Backwards First

Evidence note: most of what follows rests on primary vendor material — GitHub’s own changelog entries, documentation, and engineering blog. Vendor announcements establish what GitHub said and when; they are not independent confirmation that the behavior works as described, and no independent verification of these specific features appears in the sources gathered here. A second, separate body of evidence appears in two sections: figures produced by playagit’s own publishing pipeline and recorded in its run ledger. Those are self-measurements of this site’s process, not benchmarks of GitHub’s product, and each is attributed with its sample size and date. One third-party commentary source is cited on the billing question and is identified as such.

What GitHub Changed on August 27 and September 11, 2026: Resolution Reasons, Then Auto-Resolution

GitHub announced two changes to Copilot code review within roughly two weeks. The first, dated August 27, 2026, was published under the title "Copilot code review: Resolution reasons and expanded capabilities" (GitHub changelog) — vendor announcement, not independently verified. The second, dated September 11, 2026, covered auto-resolution and analysis updates in the same feature (GitHub changelog) — also a vendor announcement.

The sequencing is the interesting part. Resolution reasons came first: a record of why a review thread ended. Auto-resolution followed: the thread ending without a human closing it. The order suggests the accounting arrived before the automation, though neither post states that as a design rationale, and reading intent into a two-week gap is inference rather than reported fact.

The Reviewer Now Closes Its Own Loop: Self-Resolved Comments and Commit Messages Written From Applied Suggestions

Two behaviors are the substance of the August announcement, both attested by GitHub’s own changelog and not corroborated elsewhere in the sources here. First, Copilot code review resolves its own comments once the developer has addressed them. Second, when a developer applies one of its code suggestions, Copilot writes the commit message automatically (GitHub changelog, August 27, 2026).

Taken together these close a loop that previously required human action at both ends. The reviewer raises a comment, the developer applies the fix, the reviewer decides the comment is satisfied and marks it resolved, and the commit message describing the change is generated rather than written. The pull request that results has fewer human-authored artifacts in it than the same pull request would have had a month earlier. This continues a direction visible across the year — see the earlier coverage of how Copilot code review expanded to bot-authored PRs, very large PRs, and new Visual Studio controls.

Two Years of Additions: Public Preview in October 2024, All Languages in May 2025, a Command-Line Request Announced March 11, 2026

The feature’s announced history runs roughly two years, each step from GitHub’s own changelog and each therefore a vendor claim rather than an independently established one:

• October 2024 — Copilot code review entered public preview on GitHub.com (changelog, October 29, 2024).
• May 2025 — support for all languages was added, still in public preview (changelog, May 7, 2025).
• March 11, 2026 — a Copilot code review could be requested from the GitHub CLI (changelog, March 11, 2026).

The trajectory moves outward: one surface, then every language, then off the web interface entirely and into the terminal, then — in 2026 — into the closing of its own threads.

The Bill Changed Before the Features Did: Actions Minutes Consumed From June 1, 2026, Not Before

A change that is easy to miss when reading feature announcements: GitHub announced on April 27, 2026 that Copilot code review would begin consuming GitHub Actions minutes starting June 1, 2026 (GitHub changelog). GitHub’s own billing reference documents how models and pricing apply across Copilot (GitHub Docs).

The code-quality vendor Codacy published commentary framing the change as paying twice for what had previously been included (Codacy blog). That is a third-party vendor’s characterization of a competitor-adjacent product, not a neutral audit, and it should be weighed accordingly.

What matters operationally is the order of events: the metering arrived roughly three months before the auto-resolution capability. Teams that enabled Copilot code review repository-wide in early 2026 acquired a consumption line before they acquired the workflow convenience that might justify it. Anyone evaluating the September features on cost grounds is evaluating an increment on a bill that already changed.

Why This Lands on Whoever Presses Merge

Unresolved review threads are a visible, countable signal — they sit in the pull request and they are the thing a merge-approver scans. A reviewer that resolves its own comments removes that signal from the surface where a human reads it. The comment was raised and, by the reviewer’s own assessment, satisfied; what remains visible is a quieter page.

None of the cited announcements claim the resolution judgment is infallible, and none of them report an accuracy figure for it. The accountability question is unchanged by the automation: the person who presses merge still owns what ships. The change is that the evidence of what was raised and why it stopped being raised now requires a deliberate look at resolution history rather than being the default view. That reading is analysis, not something GitHub’s posts state.

What playagit’s Own Review Gate Recorded Across 88 Pipeline Runs, August 28 to September 16, 2026

For a sense of scale on how often an automated quality gate actually sends work back, playagit’s own publishing pipeline keeps a comparable record. In playagit’s own pipeline runs (n=88 runs, 2026-08-28 to 2026-09-16, as of 2026-09-16), the quality gate reviewed 630 drafts: 476 published, 116 sent back to revise, and 38 rejected outright. Derived from those counts: roughly 75.6% published, 18.4% returned for revision, 6.0% rejected.

These are this site’s measurements of this site’s own process. They are not a measurement of Copilot code review, and they establish nothing about GitHub’s product. They are offered as one recorded answer to a question the announcements leave open — what proportion of automated review verdicts are anything other than approval. Roughly one draft in four did not pass on first submission. The broader argument about why checking, not producing, has become the expensive step is developed in the earlier piece on review phases and gate evidence in agent-driven delivery.

Two further figures from the same 88 runs, same attribution and window: of 23,928 scored topics, 9,052 were held before production and 11,081 rejected, with 3,795 reaching production; 20,620 topic candidates were discovered across 4 categories from 213 distinct source hosts; and 523 posts were published, of which 220 are recorded as new and 114 as updated.

The Verification Underneath Those Approvals: 518 Independently Cross-Checked Claims and 2,019 Primary-Attested Out of 11,799

The approval rate above is only meaningful next to what the approvals were checking. In playagit’s own pipeline runs (n=88 runs, 2026-08-28 to 2026-09-16, as of 2026-09-16), across 3,134 research dossiers holding 11,799 claims, 518 were independently cross-checked and 2,019 were primary-attested. Derived from those counts: approximately 4.4% independently cross-checked and 17.1% attested by a primary source.

The gap between those two proportions is the point. Primary attestation — a vendor saying a thing about its own product — is roughly four times more common than independent corroboration, which is exactly the evidentiary situation this article is in. Again: self-measurement of this site’s pipeline, not an external benchmark.

GitHub’s Engineers Report the Upgrade Went Backwards Before It Went Forwards

GitHub published an engineering post describing how giving Copilot code review better tools initially made it worse, and what the team changed to actually improve it (GitHub engineering blog). This is GitHub reporting on its own system; the account is a vendor account, though one unusual in describing a regression rather than a win.

The post’s existence is itself the evidence worth carrying: capability added to a reviewing agent is not monotonic improvement. More tool access produced worse reviews before iteration produced better ones.

What That Reverses: Reading Auto-Resolution as a Capability Claim Rather Than a Convenience

The natural reading of self-resolving comments is that the reviewer has become confident enough in its own judgment to close threads. Set against GitHub’s own account of a capability upgrade that degraded output first, that reading is harder to sustain. Auto-resolution is better understood as a workflow convenience — fewer clicks on threads a developer has already handled — than as an assertion that the reviewer’s satisfaction judgment now equals a human’s.

Neither the changelog entries nor the engineering post makes this connection; it is an inference drawn across two GitHub sources here, and no accuracy figure for resolution decisions appears in any of them.

Where the Ecosystem Took It Anyway: Azure DevOps Reviews, a Skills Exercise Repository, and the September 7, 2026 Weekly Release

Adoption around the feature has continued regardless. An open-source project, little-fort/ado-copilot-code-review, uses GitHub Copilot to provide code reviews in Azure DevOps repositories — carrying the reviewer to a platform GitHub does not ship it on. GitHub Skills maintains an exercise repository, skills/copilot-code-review, for learning the feature. Both are stated on the repositories themselves.

Separately, GitHub’s weekly release notes for September 7, 2026 announced Jira integration in the Copilot app and adaptive model orchestration under the name Project HydraFusion in Copilot CLI (GitHub changelog, September 10, 2026) — vendor announcement, not independently verified, and named here for context on release cadence rather than because its contents bear on code review.

Developer Takeaway: Instrument the Reviewer With Usage Metrics, Including the Dedicated Agents Window, and the Follow-Up Question Worth Running

The practical step available now is measurement rather than trust. GitHub announced on September 11, 2026 that Copilot usage metrics reports include generally available metrics for activity in the dedicated VS Code Agents window (GitHub changelog) — vendor announcement. For a team enabling auto-resolution, usage metrics are the available instrument for seeing how much reviewing activity is happening and where, before deciding how much of the merge decision to hand over.

Three concrete checks follow from the above, none requiring new tooling: confirm whether the June 1, 2026 Actions-minutes consumption is visible in the organization’s billing before attributing cost to the new features; check whether reviewers on the team can still reach resolution history when threads close themselves; and record what proportion of pull requests merge with zero human-authored review comments.

The follow-up question worth running — and not run here, so it stands as a proposal rather than a result — is measurable with data a team already has: across a fixed window of merged pull requests, what share of Copilot-resolved comments were followed by a later commit or a later review touching the same lines? A resolved comment that reopens as a defect is the one number none of the announcements supply, and it is the number that would say whether auto-resolution is closing loops or closing tabs.