GitHub has expanded Copilot code review so its reviewer can run builds, tests and targeted scripts, while the Lite effort level now combines findings from multiple agents. The September 11 update also lets Copilot resolve its own review threads after a later commit addresses the issue, reducing stale feedback in active pull requests.
Featured image: GitHub.
The company describes the shell access as an analysis change rather than a new review-request workflow. Copilot can use the full shell-tool set in its SDK behind the Copilot agent firewall: that includes invoking a build, running a test suite, executing a focused script or retrieving information from an available tool or API. The practical shift is from reading a patch and nearby files toward checking some of the behavior that the patch changes.
The measured result is useful, but narrow
In GitHub’s experiments, the multi-agent Lite review produced 47% more addressed comments for high-severity findings, 31% more for medium-severity findings and 11% more for low-severity findings. GitHub also says review cost fell by about 8%. Those are internal experiment results, not a promise that every repository will see the same detection rate or cost.
“Addressed comments” is also not the same metric as defects found in production. It measures whether developers acted on the reviewer’s findings. Teams evaluating the feature should track a second set of local outcomes: repeated false positives, escaped defects, review latency and how often shell commands fail because the review environment lacks a service, secret or dependency.
Comment cleanup changes the review queue
When a pushed commit addresses a Copilot comment, the bot can now resolve that thread during its re-review. Outstanding findings stay open. This is a meaningful usability change because an open-thread count becomes a better approximation of unresolved work, instead of a mix of current findings and comments that a later commit already made obsolete.
Applied autofix suggestions also receive a generated commit-message suggestion based on the change, replacing a standard generic message. That can improve history at the margin, but the generated message still needs the same accuracy check as the code suggestion.
Shell access does not turn the bot into a merge gate by default
GitHub’s documentation says Copilot normally leaves a Comment review, not an Approve or Request changes review. Copilot approvals are separately configurable and are off by default. That distinction matters: better analysis can improve the evidence available to a reviewer without silently changing who is authorized to merge.
OWASP’s secure-code-review guidance likewise treats manual review and automated analysis as complementary. Business-logic mistakes, authorization assumptions and cross-service trust boundaries often require project context that a passing test cannot establish.
A controlled rollout needs command boundaries and auditability
Start with repositories whose normal validation commands are deterministic and do not require production credentials. Confirm which setup file and custom instructions Copilot reads, then inspect the review-session logs to see which tools actually ran. GitHub says code-review instructions are read from the pull request’s head branch, so instruction changes can be evaluated in the same pull request—but that also makes review guidance part of the code change under review.
For expensive integration suites, split a fast, unprivileged validation target from jobs that touch paid services or sensitive networks. Keep branch protection and a human owner for security-sensitive changes. The update makes Copilot’s comments more test-informed; it does not make review provenance, environment parity or approval policy optional.
TVG Analysis: The strongest part of this release is not “more agents.” It is the combination of executable checks with a cleaner unresolved-comment queue. The next useful evidence will be repository-level data showing whether high-severity findings remain precise when builds are complex and review environments differ from CI.
Related: GitHub Actions’ cache-mode controls address a different CI trust boundary.
