After fixing pull request feedback, there is still another task: deciding which conversations can be closed. When code changes and comment cleanup happen separately, an unresolved thread list can be a poor guide to what actually needs attention.

The Copilot code review update announced on September 11, 2026 addresses this part of the workflow. But does automatic resolution mean that pushing a fix completes the process?

The key is when re-review runs. Following the path from a fix to the remaining feedback helps explain what the stronger analysis can support and which decisions still belong to the team.

Addressed comments close during re-review after a push

When a later commit addresses feedback, Copilot now resolves its own comment during re-review. Outstanding feedback remains open. This behavior concerns comments written by Copilot.

Pushing a fix and starting re-review are separate events. In the existing automatic review configuration, selecting “Review new pushes” alongside “Automatically request Copilot code review” in a ruleset requests reviews after new pushes. Without the former option, automatic review runs only once for that pull request.

Teams that do not review every push can collect their fixes and request re-review through Copilot in the Reviewers section, following the documented re-review procedure. Auto-resolution needs that opportunity to examine the updated code.

Applying a suggested fix also changes: Copilot proposes a commit message based on the change instead of the standard prefilled message. A practical sequence is to compare the diff with the proposed message, commit the fix, and inspect the remaining feedback after re-review.

Shell execution and multiple perspectives add evidence for review

Comment cleanup depends on the analysis behind it. Alongside existing file-reading capabilities, Copilot code review now uses the full set of shell tools from the Copilot SDK, behind the Copilot agent firewall. These tools can run builds, tests, and targeted scripts, and retrieve information from available tools and APIs.

For example, a build result could provide evidence when investigating a possible type mismatch. That is an illustration of the capability, rather than a promise that every review runs a build or the complete test suite.

Lite also moves from a single agent to multiple agents whose findings are combined into one review. GitHub reports that its experiment increased addressed comments per review by 47% for High, 31% for Medium, and 11% for Low findings, while reducing review cost by about 8%.

Those measurements concern feedback that was addressed during an experiment. They are neither bug detection or false-positive rates nor a pricing announcement promising an 8% reduction in every customer’s bill. The useful expectation is that tool execution and multiple perspectives give the review more evidence to work with.

Match re-review frequency to execution conditions and merge requirements

The analysis updates do not change how reviews are requested or received. The operational choice is whether to re-review every push or request a pass after collecting fixes. The former provides more opportunities to update comment state; the latter gives the team more control over the number of review runs.

The current Copilot code review documentation identifies two cost components: AI credits for model use and GitHub Actions minutes for agentic capabilities. Reviews can still be generated when the required Actions workflows fail, but without those additional capabilities. Receiving a review does not establish that the expected tool-based validation took place.

Review depth is another choice. The same documentation describes Lite as standard review and Balanced as deeper analysis for complex logic, security-sensitive code, and changes across services. Balanced uses more AI credits than Lite. Even with the stronger Lite implementation, the nature of the change and its cost remain reasons to choose deliberately.

Before merging, conversation resolution, approval, and CI results each need their own assessment. The branch protection documentation defines conversation resolution, approving reviews, and required status checks as separate requirements. Copilot’s ability to execute tests does not remove the CI conditions the team has configured.

Auto-resolution handles the cleanup of Copilot feedback through re-review after a fix. Give that review a place in the workflow, automatically or manually, and use the remaining comments to guide the next human pass. The thread list can help organize the work while approval and CI continue to govern acceptance of the overall change.

Source

• Title: Auto-resolution and analysis updates in Copilot code review
• URL: https://github.blog/changelog/2026-09-11-auto-resolution-and-analysis-updates-in-copilot-code-review