What Changed on September 11
GitHub's changelog entry of September 11, 2026 says that when you push a commit that addresses a Copilot code review comment, Copilot now resolves that comment during its rereview. Feedback that is still outstanding is meant to stay open. The same entry says that when you apply a Copilot suggestion, the commit message is now generated from the change instead of the standard auto-filled text.
Two details matter more than the headline. First, the resolution happens during a rereview, not at the moment of the push. Second, neither the changelog nor the Copilot code review concepts page, as checked on September 14, describes a switch for turning auto-resolution off. Assume it applies to rereviews in your repositories until GitHub documents a control.
What the Rule Proved Before, and What It Proves Now
The protected-branch documentation describes "Require conversation resolution before merging" as requiring all comments on the pull request to be resolved before it can be merged. The rule checks resolved state. Nothing in that description records who resolved a thread.
That rule was already weaker than many teams assumed. According to GitHub's pull request commenting documentation, a conversation can be resolved by the person who opened the pull request or by anyone with write access. So the author could close a reviewer's thread without the reviewer's involvement. Before this change, GitHub's documented resolution path put that action in the hands of the pull request author or someone with write access. That still did not prove that the reviewer had seen or accepted the fix.
After September 11 a thread can be opened by Copilot and closed by Copilot without any person touching it. A merge that passes the conversation-resolution rule now proves that every thread is marked resolved. It no longer proves that a human read the finding, judged the fix, or even knew the thread existed. GitHub itself says Copilot is not guaranteed to spot all problems and that its feedback should be supplemented with a human review.
If the rule was your only mechanism for making sure a security finding got human attention, you have lost that mechanism. The decision questions in the AI pull request review checklist still describe what a human reviewer should establish; this article is about where that human judgment now has to be recorded.
Know When Auto-Resolution Actually Fires
The concepts page says that unless Copilot is configured to review each push, it reviews a pull request only once, and a rereview otherwise has to be requested through the Re-request review button next to Copilot's name. Automatic review can be configured to run every time a new commit is pushed. Auto-resolution therefore behaves differently in two repository configurations that look identical from the branch rule's point of view.
In a repository that reviews once, Copilot threads stay open after the fix commit until someone re-requests the review. A developer who wants the merge button to turn green will learn to click that button, and the click is the moment resolution happens. In a repository that reviews every push, resolution happens on every commit with no click at all. Record which of the two your repository is, because your test results only apply to that configuration.
The per-push configuration also has a cost dimension. As of September 14, the concepts page estimates that a review typically consumes $0.05 to $1 USD worth of AI credits at the default Lite effort level and $0.25 to $5 USD at Balanced effort, plus GitHub Actions minutes. Every push that triggers a rereview to get threads resolved is another review at those rates.
Run the Partial-Fix Check
Use a disposable repository or a branch that cannot deploy. Enable Copilot code review, enable the conversation-resolution rule on the target branch, and set the review trigger to the configuration your real repositories use. From one base commit, open four pull requests that each seed the same change Copilot reliably comments on, such as an unchecked return value and a missing null check in the same function. You need at least one Copilot thread per pull request that names two distinct problems, so keep the seeded defects adjacent. Then push exactly one commit to each pull request and trigger the rereview the way your configuration does: automatically on push, or through Re-request review.
| Case | Commit after the Copilot comment | Required result |
|---|---|---|
| A: full fix | Both problems named in the thread are corrected | Thread resolved during the rereview; merge button no longer blocked by that thread |
| B: partial fix | Only the first of the two problems is corrected | Thread stays open, or Copilot posts a follow-up on the remaining problem; the rule still blocks |
| C: unrelated commit | A whitespace change in another file | Thread stays open; nothing is resolved |
| D: cosmetic edit | Rename a variable on the flagged line without fixing either problem | Thread stays open; a resolved thread here is a failed case |
Case B is the one the changelog promise depends on. GitHub says outstanding feedback stays open. Your record should show whether "outstanding" is judged per thread or per problem inside a thread, because a thread that bundles two findings and gets closed on one fix is exactly the failure mode the branch rule can no longer catch. Case D tests whether a diff that touches the flagged line is enough to count as addressing it.
For each case, store the pull request URL, the head SHA before and after the commit, the review trigger configuration, the thread ID, the thread state before and after the rereview, who or what changed that state, any follow-up comment Copilot posted, and the merge-button state. Score with one sentence:
PASS when observed_thread_state == expected_thread_state
AND resolver_identity_is_recorded == true
AND rule_blocks_merge_on_open_thread == trueDo not score the quality of Copilot's comments in this exercise. The input is a controlled commit; the output is the thread state and the rule decision. Comment quality is a separate evaluation with different inputs, and the collection of AI code review comment patterns is a better starting point for it.
Decide Which Finding Classes Stay Human-Resolved
Auto-resolution is useful for the findings you never wanted a human to babysit: naming, formatting, an unused import, a missing docstring. For those, a thread that closes when the fix lands is strictly better than a thread the author closes by hand. The policy question is which classes are the opposite: where the thread closing must remain a human act because the fix itself needs a second judgment.
A workable first list is authentication and authorization changes, secrets and credential handling, input validation on external boundaries, data deletion or migration logic, billing and payment paths, and anything that changes a security control. For these, the resolved state of a Copilot thread is informational. The evidence that a person judged the fix has to live somewhere the bot cannot write: a code-owner approval on the affected path, a separately administered required status check, or a signed review comment from a named owner that states what was verified.
This is the same design as the independent lock in the earlier article on proving a Copilot approval is independent before it counts. There the concern was the approval count; here it is the thread count. In both cases the fix is to stop asking a state that Copilot can produce to prove something only a person can prove. Copilot approvals, for the record, remain in public preview and do not count toward required approvals by default.
Read the Ensemble and Shell-Tool Numbers as Vendor Test Results
The same changelog entry reports two analysis changes. The Lite effort level now uses an ensemble of agents instead of one. In GitHub's own experimentation, the ensemble increased the average number of addressed comments per review by 47% for high severity findings, 31% for medium, and 11% for low, while reducing review cost by about 8%. GitHub does not state the period, the sample size, the baseline population, or how severity was assigned.
Note what the metric measures: addressed comments per review, not defects found or false positives avoided. The post does not define "addressed"; if it means a developer acted on the comment, the number rises with better findings but also with more findings that are cheap to accept. It is a reasonable internal signal for GitHub and no evidence about your repositories until you measure it there. Treat the 8% cost figure the same way; it describes GitHub's test population at the default effort level, not your bill.
The second change is that Copilot code review now uses the full set of shell tools from the Copilot SDK, which GitHub describes as "running behind the Copilot agent firewall", to run build commands, tests, and targeted scripts against the code under review. GitHub says its experiments showed more positive developer feedback, more high severity findings, and fewer nits, with no numbers attached. Neither the changelog nor the concepts page describes what those tools may execute, for how long, or with what access, so do not write an execution boundary into your policy that the documentation does not give you. If your repository has scripts that a review run should never execute, verify that yourself in the disposable repository before enabling per-push reviews.
The Policy Record Is the Deliverable
Write down, per repository: the review trigger configuration, whether the conversation-resolution rule is enabled, the four partial-fix results with dates and SHAs, the list of finding classes that require a human-owned signal, and what that signal is. Add the retest triggers: a change to the review trigger, a change to the branch rule or ruleset, a change of effort level, and any GitHub update that mentions resolution or rereview behavior.
The broader AI merge-readiness checklist covers the rest of what a merge needs. This record covers one narrow question: now that the reviewer bot can close its own threads, what in your merge policy still proves a person looked. If the honest answer is nothing, the fix is not to disable auto-resolution, which the sources do not show you can do, but to put the human evidence somewhere the rule cannot be satisfied without it.