GitHub Copilot Can Approve Pull Requests, Then Close Its Own Comments

A pull request approval has always meant a person’s name sitting next to a green check — someone read your change and put themselves behind it, and if it broke later, you were both on the hook. That informal contract is what GitHub spent eleven days in September 2026 rewriting. On 1 September, GitHub Copilot code review gained the ability to submit an approving review that satisfies a repository’s required-approval rule “the same way a teammate’s approval would.” Ten days later, on 11 September, it gained a second power: it can now mark its own review comments resolved once a later commit addresses them, and write the commit message for the fix it just suggested . Alone, each is a convenience. Stacked, they let an objection get raised, fixed, described and closed with no human judgment recorded — the exact tension GitHub’s own safeguards were built to answer, and the one they can’t fully resolve.

The approval loop closes without a name attached

Copilot’s code review has posted an “approval assessment” in its overview comment for months, but the verdict was informational until now. GitHub’s documentation confirms that once repository, organization and enterprise settings all permit it, “Copilot can submit an approving review that satisfies your repository’s required-approval rule the same way a teammate’s approval would” — the exact shift DevOps.com called the moment “code review stops being advice and becomes authority.” The second change compounds the first. Flag an issue on your pull request, click apply on Copilot’s autofix, and Copilot now writes the commit message for that fix itself; on its next pass, it sees the commit addresses its own earlier comment and marks that comment resolved. That autofix already sits inside a self-repair loop shown to damage working code more often than it fixes when unanchored to a failing test . Objection, remedy, description and closure now share one author, and the thread reads as settled before anyone scrolls past it. If your repo enforces a required-approval rule, that’s the check mark unblocking your merge — and it can now come from a reviewer with no name to ask on Monday morning, while you’re still the one explaining what shipped.

GitHub built real brakes, but no speedometer for them

None of that is nothing. Approvals are off by default and must be enabled at enterprise, organization and repository level; admins can scope them to specific file paths; a bare approval assessment never counts toward merge requirements alone; and a new commit after Copilot approves automatically dismisses that approval. GitHub also has evidence the reviewer earned some of that trust: its newer ensemble-review mode — which now runs builds, tests and targeted scripts behind Copilot’s agent firewall instead of only reading files — produced a 47% increase in addressed high-severity comments, 31% for medium and 11% for low, at roughly 8% lower cost, a real gain in how often developers act on what Copilot flags. What GitHub hasn’t published is a number for the new capability itself — how often an approval, rather than a comment, is correct. Mitch Ashley of The Futurum Group frames it bluntly: “Approval is where code review stops being advice and becomes authority, and GitHub just moved Copilot across that line.” DevOps.com’s Tom Smith adds the missing measure: engineering leaders will want dashboards showing how often it approves correctly — and GitHub doesn’t hand those over. That gap fits the shape of the reviewer that billed Wealthfront four dollars a pull request to mostly say nothing — the industry keeps shipping judgment before it ships a scorecard for that judgment.

The only field data available measures a different question

The closest thing to independent evidence comes from a different tool and a different unit of analysis. Hong Yi Lin, Mingzhao Liang, Patanamon Thongtanunam and Kla Tantithamthavorn’s study of CodeRabbit measured how developers treated 31,073 individual review comments across 10,191 real pull requests, and found 56.3% rejected — mostly dismissed as false positives, redundant, or out of scope. That’s a measurement of single remarks, not of a whole pull request’s fitness to merge, and CodeRabbit isn’t Copilot. Read across to what a required-approval sign-off asks of a reviewer — one compressed judgment across a whole diff, rather than many separable comments — and a rejection rate above one in two suggests that sign-off deserves at least as much scrutiny, even though nobody has measured it directly. That absence is the real finding: the industry has data on how often the agent is annoying and none yet on how often it’s right.

None of this needs alarm. GitHub shipped configuration, scoping and dismissal controls a less careful team would have skipped, and its review now surfaces more real findings and fewer nits than a year ago. But Pipeline’s earlier read on whether code review had ended or just relocated assumed a human still stood at the end of it, however far down the pipeline it had moved. Wire these two capabilities together and that assumption quietly stops holding: the same name can no longer sit next to the green check, because there isn’t one to put there. The merge trail still exists. It just doesn’t mean what everyone kept assuming it meant.