Copilot now resolves addressed comments during rereview

GitHub Copilot code review now resolves its own comments when a later commit addresses the feedback. The resolution happens during rereview, leaving outstanding comments open. For a developer returning to a busy pull request, that means less time closing threads that have already been dealt with.

The September 11 update also changes how teams should read their review reports. A smaller list of open comments can reflect automatic cleanup after fixes. It does not necessarily mean Copilot found fewer problems or that the original change was better.

What happens when Copilot reviews the next commit

The sequence starts with a Copilot review comment. A developer changes the code and pushes a later commit. During its rereview, Copilot determines whether that commit addresses the feedback. GitHub says addressed comments are resolved automatically and outstanding feedback stays open.

That timing matters. The announcement describes what happens during rereview; it does not say every push in every repository automatically requests one. Teams that need help with those triggers can check our explanation of automatic Copilot review rulesets.

Use the remaining open comments to decide what to investigate next. When checking an important fix, return to the original concern, read the changed code, and inspect the relevant test result. Thread resolution records Copilot's assessment of its feedback. Your normal code review and release requirements still determine whether the change should ship.

Open comments and useful findings answer different questions

An open-comment count is a snapshot of unfinished discussion. A useful-finding count asks how much of the review helped improve the code. Automatic resolution can reduce the first without reducing the second.

This distinction matters if a team copies the current number of open threads into a weekly report. After rereview, findings that prompted fixes can move out of that count. A report that labels it “issues found” would then lose evidence of useful work precisely because someone addressed it.

Our recommendation is to label the measure narrowly: open Copilot feedback at the time of collection. If you also want to understand review quality, retain the original finding and its eventual outcome separately. A valid issue that was fixed, a false positive that was dismissed, and feedback still awaiting investigation should remain distinguishable.

You do not need a new dashboard to make this useful. In a review retrospective, inspect a small set of completed pull requests and follow the comments through to the fixes. Discuss whether the findings were correct and whether the changes addressed the underlying behavior. That conversation can reveal more than comparing unresolved-thread totals taken at different points in the review cycle.

The review agent also has more ways to inspect code

GitHub says Copilot code review now uses the full set of shell tools from the Copilot SDK behind the Copilot agent firewall. Its examples include running builds and tests, executing targeted scripts, and retrieving information from available tools and APIs.

These are additional capabilities available to the review agent. The announcement does not establish that every review runs a project's entire test suite. If a review cites a test or build result, read what was actually run and which part of the change it covers. Keep the required checks that your team already relies on.

Lite reviews now use an ensemble of agents rather than one agent working alone. Each contributes findings that Copilot combines into one review. GitHub reports improved results in its own experiments, but those experiments do not tell you how useful the next review will be in your repository.

This update is separate from the forthcoming change to the Default review effort setting. If you compare Lite reviews over time, note that its implementation has changed even when your selected effort level has not. Otherwise, you may attribute a difference in findings entirely to the developers or the code under review.

Read the suggested commit message before accepting it

When you apply a code suggestion from a Copilot review comment, Copilot now suggests a commit message based on the change instead of filling in the standard message.

That can make the history easier to scan. Treat it as a draft: check that it describes the diff and does not claim a test passed or a bug was fully fixed unless you have checked that. A clear commit message helps the next reviewer understand the change; it should not supply evidence that the review itself lacks.

The immediate benefit of this release is a cleaner follow-up process. Let Copilot close the feedback it considers addressed, use the open threads to organize remaining work, and keep the original findings when you want to evaluate how useful the review was.

Source

GitHub: Auto-resolution and analysis updates in Copilot code review, September 11, 2026. Product behavior above comes from this announcement; reporting and review recommendations are BaristaLabs guidance.