Correction, October 13, 2026: GitHub says review shell tools run behind the Copilot agent firewall. External effects depend on the environment and access available to those tools.
What happened
GitHub shipped a changelog update on September 11 changing how Copilot’s code review feature checks and manages its own feedback on pull requests.
The September 11 release makes three changes to Copilot’s code review. First, auto-resolution: “when you push a commit that addresses a Copilot code review comment, Copilot now resolves that comment during its rereview,” instead of leaving you to close out threads by hand. Second, when you accept one of Copilot’s suggested code changes, it now writes a commit message based on what the suggestion actually changes, rather than a generic one. Third, Copilot’s review agent now uses, in GitHub’s words, “the full set of shell tools from the Copilot SDK,” including running build commands, running tests, executing targeted scripts, and pulling information from other available tools and APIs, to validate its findings before it posts them.
GitHub also says reviews run at its lower-cost “Lite” effort tier now use an ensemble of multiple review agents working together instead of one. Internally, GitHub reports this raised the average number of addressed comments per review by 47% for high-severity findings, 31% for medium, and 11% for low, while cutting review cost by about 8%. Check access for your plan and repository, along with the available auto-resolution controls, before relying on the feature.
Why it matters
The auto-resolution feature changes what “no open comments” means on a pull request. Previously, an open Copilot comment stayed open until you closed it, so the list of open threads was a list you controlled. Now Copilot decides, on its own judgment, whether your latest commit actually addressed what it flagged. If it judges that incorrectly, a comment that still matters can disappear from your open-threads view marked as resolved, not because the underlying issue is fixed, but because Copilot believed a later commit fixed it.
The shell-tool change is worth watching for a different reason. Copilot’s review agent isn’t just reading your diff anymore. It’s running build commands, tests, and “targeted scripts” against your repository to check its own findings. GitHub says those tools run behind the Copilot agent firewall. Check the environment and network access before assuming that scripts cannot affect other services.
A script may call an external API, write to a shared database or trigger a webhook, an automatic message to another system. Those effects depend on its credentials and reachable services. Keep review scripts on test data and sandbox services, as you would for CI, the automated checks your project runs on code changes.
Who should care
Anyone using Copilot code review who treats a clean, all-resolved comment thread as their signal that a pull request is ready to merge. Also anyone whose repository’s build or test scripts have side effects that reach outside an isolated test environment, since those scripts can now run as part of an automated review rather than only under your own CI setup.
What builders should do next
In a disposable repository, compare two pull requests where Copilot leaves a review comment. On one, push a commit that fully fixes the issue. On the other, push a commit that only partially addresses it or changes a nearby line. Check whether Copilot leaves the partial fix open and whether its note on the full fix shows that it verified the change. If it resolves the partial fix too, inspect resolved threads and keep independent checks before merging.
Separately, inspect build and test scripts for external effects. If someone else maintains them, ask which credentials and services they can reach during a review run.
End of article