GitHub Copilot can now close its own code-review comments after a developer fixes the problem it flagged. The September 11 update also generates a tailored commit message when someone applies a Copilot suggestion, removing two small chores from the process of checking code before it joins a project.
The consequential change is the resolved label. According to GitHub’s announcement, Copilot examines a later commit, a saved set of code changes, during a follow-up review and resolves comments whose underlying feedback it considers addressed. Feedback it considers outstanding stays open. That should make the remaining discussion easier to navigate, although the closed threads now reflect the AI’s judgment about whether its concerns were answered.
A developer pushes a follow-up commit, then Copilot must review the changes again before it can resolve an addressed comment. GitHub’s documentation says automatic review of subsequent commits requires the “Review new pushes” setting; otherwise, a developer must request rereview manually. A resolved thread records Copilot’s assessment, without revealing its decision rule or replacing human validation.
GitHub discloses the broad basis for that assessment: a later commit evaluated against the earlier feedback. It does not specify a fixed test, confidence threshold or required evidence for deciding that a fix is adequate. Nor does it publish rates for comments closed incorrectly or left open after a successful fix.
The same release gives the review agent more ways to investigate code. Alongside file-reading tools, it can use shell tools to run builds, tests and targeted scripts behind the Copilot agent firewall. Those capabilities could help validate a change, but GitHub does not say which, if any, determine automatic resolution. A closed comment therefore does not establish that a test ran or passed.
The commit-message change is more straightforward. Applying a suggestion from a Copilot review comment now produces a proposed message describing that particular change instead of the previous standard message. GitHub provides no representative examples in the announcement. The message is a description of the edit, not evidence that the edit fixes the problem.
What remains for reviewers
GitHub describes both workflow features as available now, without a separate breakdown by plan or interface. Its documentation lists code review on all paid Copilot plans across GitHub.com, supported editors, CLI and Mobile, with Azure DevOps in public preview. That broader availability does not establish that automatic resolution and tailored commit messages appear in every interface. Organization policy can also govern access.
GitHub’s review guidance still places people after the AI in the checking process. Developers must validate its feedback and review the resulting code; Copilot can miss problems and make mistakes. Resolving one concern cannot establish that the whole change is correct or secure.
Formal approval is a separate question. Under GitHub’s documented approval rules, Copilot reviews do not satisfy required approvals by default. Administrators can explicitly enable a public-preview feature that lets Copilot approvals count. Required human approvals and automated checks therefore depend on the repository’s configuration.
We would use the quieter review queue to focus attention, while checking consequential fixes against the original concern and the resulting code. Copilot can retire its comment; the team still has to decide whether the change is ready.