On September 11, 2026, GitHub changed two visible parts of Copilot Code Review: Copilot's own comments that have already been addressed can now be resolved automatically during a re-review, and code suggestions applied through the interface now receive a commit message generated from the actual change. At the same time, the review engine gained more analysis tools and a multi-agent approach at the Lite effort level.
The practical result is less thread cleanup and fewer generic commit messages when accepting suggestions. But the update does not turn every push into a re-review, does not close human feedback, and does not replace the decision to accept, test, and merge code.
What changed in the pull request workflow
| Step | Relevant behavior now | What it means in practice |
|---|---|---|
| Copilot comment already addressed | During a re-review, Copilot can resolve its own comment when a later commit addresses the underlying feedback. | Old threads can leave the pending list without manual resolution. |
| Comment still not addressed | It stays open. | The open-thread list is more likely to focus on work that still needs attention. |
| New push | It does not trigger a re-review by itself unless the repository is configured to review new pushes. | Without that setting, someone must request the re-review manually. |
| Applying a Copilot suggestion | GitHub generates a contextual commit message based on the suggested change. | The message becomes a more descriptive draft instead of a generic default. |
| Review analysis | Copilot now uses a broader set of shell tools and, at the Lite effort level, an ensemble of agents. | The review can validate more aspects of the code without changing the basic way a review is requested. |
Auto-resolution depends on a re-review, not just a push
The most important detail in the update is the sequence of events. GitHub says the comment is resolved during the re-review when a later commit addresses the issue behind the feedback. A typical sequence therefore looks like this:
- Copilot reviews the pull request and leaves comments.
- You change the code to address some of them.
- You push the new commit.
- Copilot runs a re-review, either manually requested or triggered by a rule that reviews new pushes.
- During that new analysis, comments Copilot considers addressed can be marked resolved; anything still outstanding remains open.
By default, pushing a new commit to a pull request that Copilot already reviewed does not force another review. To get automatic re-reviews on every push, the repository must enable automatic code review and the Review new pushes option in its ruleset. Otherwise, a re-review is requested from the pull request's Reviewers menu.
The scope also matters: the announcement is about comments created by Copilot Code Review itself. It does not say that human reviewers' threads are automatically closed. GitHub's documentation also says that replies added to Copilot review comments are visible to people but not to Copilot. In practice, the automation is driven by the code change evaluated during re-review, not by a written conversation with the bot.
Before and after in a pull request: a simple example
Imagine a pull request with three Copilot comments: one about error handling, one about a missing test, and a third about duplicated logic. The developer fixes the error handling and duplication but leaves the test for a later commit.
Before the update: even after the fixes were applied, there could still be manual work to close threads that were no longer relevant.
With the update: after the push and re-review, Copilot can automatically resolve the two comments it considers addressed and keep the test comment open. The gain is not “Copilot decided the pull request is ready”; it is a potentially cleaner list of remaining work.
There is a useful caveat: GitHub's current documentation still warns that, during re-reviews, Copilot may repeat earlier comments even when they were resolved or downvoted. Auto-resolution therefore reduces tracking work, but it should not be treated as a guarantee that the same or similar point will never appear again.
Smart commit messages: the feature is narrower than it sounds
The second visible change appears when you apply a code suggestion provided in a Copilot Code Review comment. Instead of filling a standard message, Copilot generates a message based on what the suggestion changes.
This does not mean Copilot rewrites the messages for every commit in the pull request, and it does not automatically generate smart descriptions for commits you make locally. The trigger described by GitHub is the suggested changes flow attached to Copilot's own review comment.
The normal suggested-change workflow still matters: you can apply one suggestion on its own or batch several suggestions into a single commit. GitHub still presents a commit-message field before the commit is confirmed. The practical approach is to treat the generated message as a draft and check that it accurately describes the actual scope, especially when multiple suggestions are batched.
What changed behind the analysis
The September 11 announcement also included changes that do not alter the workflow buttons but can affect the quality of the feedback.
- More shell tools: in addition to the file-reading tools already used during review, Copilot Code Review now uses the full set of shell tools from the Copilot SDK, running behind the agent firewall. GitHub lists running builds, tests, targeted scripts, and retrieving information from available tools and APIs as examples.
- Multiple agents at the Lite effort level: Lite reviews now use an ensemble of agents whose findings are combined into a single review.
In GitHub's reported experiments, the multi-agent approach increased the average number of addressed comments per review by 47% for high-severity findings, 31% for medium-severity findings, and 11% for low-severity findings, while reducing review cost by about 8%. Those figures are GitHub experiment results, not a promise that every repository will see the same performance.
The changelog explicitly separates these analysis improvements from the user workflow: they deepen the review, but they do not change the basic way you request or receive one.
What still requires human judgment
- A resolved comment is not proof that the code is correct. It means that, during re-review, Copilot assessed that a later commit addressed its earlier feedback.
- The re-review still has to happen. It can be requested manually or configured to run after new pushes.
- Outstanding feedback remains outstanding. The feature is designed to keep unresolved items open.
- Human review comments remain the team's responsibility. The announced auto-resolution applies to Copilot's comments.
- Applying a suggestion still deserves a diff review. A better commit message does not validate the change by itself.
- The merge decision remains part of the repository's process. By default, Copilot Code Review submits a comment review; Copilot approvals are a separate, configurable capability.
A practical workflow that uses the feature without delegating the pull request
- Request the initial Copilot review, manually or through automatic review settings.
- Read the comments and prioritize higher-impact findings before applying suggestions in bulk.
- When a code suggestion is available, inspect the diff before applying it.
- If you apply the suggestion, review the smart commit message as well and edit it if it does not match the true scope of the commit.
- Push the fixes.
- Make sure a re-review will occur: request it manually or confirm that Review new pushes is enabled.
- After the re-review, look at both what was resolved and what remains open. A disappearing thread is a tracking signal, not a replacement for tests or technical review.
- Before merging, keep the project's normal safeguards: CI, tests, required human review, and an impact check for the change.
The real gain from the update
The main benefit is operational. Copilot Code Review now maintains the state of its own comments more effectively after the code changes and produces more useful commit-message drafts when suggestions are accepted. That removes two mechanical tasks — cleaning up addressed threads and rewriting generic messages — without changing the author's and reviewers' final responsibility for the pull request.
Teams that already use automatic re-reviews are likely to notice the change immediately: after each reviewed push, the open comments can better reflect what is still missing. Teams that run Copilot only once per pull request will see the auto-resolution behavior only when a re-review actually runs.
