
Copilot Now Closes Its Own Review Comments. Your Merge Rule Only Checks That None Are Open.
On 11 September GitHub made Copilot code review resolve its own comments. When a later commit addresses a Copilot comment, Copilot marks the thread resolved during its rereview. It applies to existing users automatically, with nothing to switch on.
Ten days earlier Copilot code review gained the ability to approve pull requests, and admins can let that approval count toward required approvals on paths they choose. Add the 27 August change that gives Copilot cloud agent pull requests a full agentic review, and GitHub's own agents now write a change, review it, and close the review comments, with approval available on the paths admins allow.
The "require conversation resolution" rule counts open threads. It does not care who closed them or why. If your team reads a clean conversation list as proof that a person looked, audit how threads get resolved, keep Copilot approvals to paths you would merge unread, and pick a review effort level before the default changes on 28 September.
A pull request with zero open conversations used to mean something specific. Someone left a comment, and someone else, usually the author, decided it had been handled and clicked Resolve. That click was a small human judgment, and plenty of teams built their merge process on top of it without ever writing that down.
As of last week, on comments Copilot wrote, the click can come from Copilot.
Three changelog entries in fifteen days
Each one reads like routine product work. The effect comes from the order they shipped in.
27 August. Copilot code review started reviewing bot-authored pull requests when an organization policy allows it, including pull requests from Copilot cloud agent, which now get "a full agentic review" instead of the reduced one. The old limit of 300 files or 20,000 lines was removed. The same entry added resolution reasons, so a person resolving a Copilot comment can mark it Addressed, Won't fix, or Incorrect.
1 September. Copilot code review can approve pull requests, in public preview on Pro, Pro+, Max, Business and Enterprise. Every review now carries an approval assessment in its overview comment, which on its own does not count toward merge requirements. Copilot approvals, which do count, are off by default. At the repository level there are two toggles, "Allow Copilot to approve pull requests" and "Allow Copilot approvals to count toward merge requirements", plus up to 15 path globs, and an approval only counts when every changed file matches one of them. A new commit dismisses the approval, the same as it would a teammate's.
11 September. Auto-resolution. GitHub's wording: "Comments are automatically resolved when a later commit addresses the underlying feedback." The review agent also got the full shell tool set from the Copilot SDK, so it can run builds, tests and scripts during a review. And the Lite effort level became an ensemble of agents, which in GitHub's experiments raised the average number of addressed comments per review by 47% for high severity findings, 31% for medium and 11% for low, at about 8% lower review cost.
That changelog says the changes "do not affect how you request or receive reviews." For the request flow that holds. For what a resolved thread tells you, it does not.
What the merge rule checks
Branch protection describes the setting as: "Requires all comments on the pull request to be resolved before it can be merged to a protected branch." The ruleset parameter, required_review_thread_resolution, says: "All conversations on code must be resolved before a pull request can be merged."
Neither mentions who resolves. The rule has always been a count of open threads. What changed is that one category of thread can now reach zero without a person deciding anything.
When a Copilot comment was a suggestion that a human either fixed or dismissed, the human's click carried the judgment and the count reflected it. With auto-resolution, Copilot's rereview decides whether its own feedback was dealt with, and the gate reads that as done.
The rereview has a record here. Community discussion #190754, opened in March, documents Copilot raising the same suggestion across four review rounds on an Azure SDK pull request after the author explained each time why it did not apply. Other users added reports of five to seven rounds through July. GitHub's docs still warn that Copilot "may repeat the same comments again, even if they have been dismissed." That was the rereview reopening what a human closed. The new feature has the rereview closing things itself. Both rest on the same call: does this commit deal with this comment.
How the loop closes
Take a repository that has enabled Copilot approvals for a set of paths and requires one approval.
Someone opens a pull request and Copilot leaves four comments. The author pushes a fix. With "Review new pushes" enabled in the ruleset, Copilot reviews again, decides three comments are addressed and resolves them. The author pushes once more, the fourth thread closes, the assessment says ready, and Copilot approves. If every changed file matched the globs, the merge button is green and nobody else read the diff.
On paths you picked deliberately, that is the point of the setting, and GitHub made it opt-in and path-scoped for that reason. Auto-resolution reaches further, because it applies whether or not anyone enabled approvals. A team with a required human approver and a conversation-resolution rule now has one of its two signals partly produced by the reviewer the rule was meant to check.
Copilot cloud agent pull requests add a gap. GitHub's docs say that if you asked Copilot to create the pull request, your approval won't count: "Another reviewer must approve the pull request before it can be merged." They do not say whether a Copilot code review approval can be that other reviewer. A detailed write-up on the approvals setting, published 13 September, listed that as undocumented, along with its interaction with CODEOWNERS, with "Require approval of the most recent reviewable push" and with auto-merge. Try it in a scratch repository before assuming either answer.
What to change this week
Write down what resolved means. If conversation resolution is part of how you show review happened, for an auditor or for your own incident reviews, record that Copilot threads can now close without a person. Then decide whether that is acceptable. The rule itself cannot tell the two cases apart for you.
Measure how threads close. The GraphQL PullRequestReviewThread object exposes isResolved, isOutdated and resolvedBy. resolvedBy is typed as User, and Copilot is not an ordinary user account, so check what the field returns on a thread Copilot resolved before you build a report on it. A weekly query over merged pull requests that counts Copilot-authored threads resolved with no human reply shows how often this happens in your repositories.
Control when rereviews run. Auto-resolution happens during a rereview. Unless "Review new pushes" is on, Copilot reviews a pull request once, and later passes only happen when someone re-requests one. Leaving that option off ties the closing step to a person asking for it.
Treat the glob list as the policy. If you enable Copilot approvals, every changed file must match a glob, so docs/** or a generated API client is a reasonable scope and ** is not. Keep authentication code, CI and infrastructure definitions, and database migrations out of the list. If 15 globs feels tight, the scope is probably too wide.
Pick an effort level before 28 September. On that date the Default effort level moves from Lite to Balanced. GitHub's docs estimate Lite at $0.05 to $1 of AI credits per review and Balanced at $0.25 to $5. If you enable "Review new pushes" to get auto-resolution on every commit, each push becomes a review at the new rate. To stay on Lite, select Lite explicitly instead of Default.
Stale Copilot comments were noise, and nobody enjoyed clicking Resolve on something they had already fixed, so the feature makes sense. It also changes what the checkmark records. For Copilot's threads, "all conversations resolved" now records the reviewer agreeing with its own earlier review. Find out which of your gates were leaning on the old meaning before an auditor asks.