GitHub Copilot code review auto-resolution: verify fixes without mistaking closed threads for merge proof
Quick answer
GitHub updated Copilot code review on September 11, 2026. During a re-review, Copilot can now automatically resolve its own review comments when a later commit addresses the underlying feedback. Unaddressed feedback stays open. Copilot also writes contextual commit messages when you apply its suggestions, uses more shell tools behind the Copilot agent firewall, and runs an ensemble of agents for Lite reviews.
The safe operational rule is simple: an auto-resolved thread is a triage signal, not independent proof that the fix works or that the pull request is safe to merge. Bind every re-review to the current head SHA, run the relevant deterministic checks, and preserve human and repository merge gates.
Who this is for
This guide is for developers and repository administrators who use Copilot code review on pull requests, especially teams that enable automatic reviews for new pushes. It addresses one task: letting auto-resolution reduce review noise without allowing a closed conversation to replace test, approval, or merge evidence.
If you are deciding whether a Copilot approval may count toward required reviews, use the separate Copilot approval and merge-requirements checklist. Auto-resolution and approval are different states.
What changed—and what did not
The new behavior happens during a re-review. Pushing a commit alone does not guarantee a re-review: GitHub's documentation says you must either request one manually or configure automatic code review with Review new pushes enabled. When the re-review finds that a later commit addressed Copilot's feedback, it can resolve that conversation. Feedback it still considers outstanding remains open.
GitHub also expanded review analysis. Copilot code review may now use the full shell-tool set exposed by the Copilot SDK, behind the Copilot agent firewall, to run builds, tests, targeted scripts, or retrieve relevant information from available tools and APIs. Lite effort now combines findings from an ensemble of agents. GitHub reports better comment outcomes and lower review cost in its experiments, but those upstream aggregate results are not a performance guarantee for your repository.
Three boundaries remain unchanged:
- Copilot can miss issues and make mistakes; GitHub recommends validating its feedback and supplementing it with human review.
- A resolved conversation does not prove that CI passed, the expected test ran, or the reviewed head SHA is still current.
- By default, Copilot leaves a Comment review rather than an approval. Approval assessment, approving-review authority, required-review credit, and conversation state are separate controls.
Keep two ledgers, not one checkbox
Treat conversation state and validation state as separate ledgers.
| Ledger | Useful fields | What it proves |
|---|---|---|
| Review conversation | thread ID, severity, original SHA, re-review SHA, open/resolved, resolver | What Copilot currently considers addressed |
| Release validation | head SHA, command, exit code, artifact or check URL, reviewer, timestamp | What was independently tested on that revision |
A pull request is not ready because every Copilot thread is resolved. It is ready only when the conversation ledger has no accepted blockers and the validation ledger satisfies the repository's real merge contract.
A six-case rollout canary
Enable the behavior first on one low-risk repository or path group. For each canary, record the head SHA before the push, the new head SHA, whether a re-review actually ran, the thread transition, and independent checks.
| Case | Change to push | Expected result |
|---|---|---|
| Exact fix | Correct the line identified by Copilot and add a focused test | Comment may resolve; the focused test and CI still must pass on the new SHA |
| Cosmetic edit | Reformat or rename nearby code without fixing the defect | Original feedback should remain open |
| Partial fix | Handle one branch but leave the failing edge case | Feedback remains open, or a human reopens it after inspecting the test gap |
| Regression | Fix the comment, then introduce the same failure elsewhere | Thread state cannot be used as proof; repository checks must catch the regression |
| No re-review | Push a valid fix with Review new pushes disabled | No automatic transition is expected until a re-review is requested |
| Stale receipt | Start validation on SHA A, then push SHA B | Results for SHA A are rejected as merge evidence for SHA B |
Include one suggestion-application test. Confirm that the generated commit message accurately describes the actual patch, then edit it if necessary. A smarter default message improves traceability, but the commit author still owns its accuracy.
Use a fail-closed merge decision
Did a re-review finish for the current head SHA?
├─ no -> keep previous thread state non-authoritative
└─ yes
-> did Copilot resolve the comment?
├─ no -> address, reject with rationale, or escalate
└─ yes
-> did the required deterministic validation pass on the same SHA?
├─ no -> do not merge; reopen or investigate
└─ yes -> continue through human approval and every repository rule
Do not build an automation that merges when unresolved_conversations == 0. That metric can be useful for triage, but it does not encode test coverage, code-owner requirements, security scanning, deployments, or approval policy.
Copyable re-review receipt
feature: copilot-code-review-auto-resolution
repository: owner/example
pull_request: 123
original_head_sha: abc123
rereview_head_sha: def456
review_new_pushes_enabled: true
rereview_completed: true
threads:
- id: PRRT_example
severity: high
state: resolved-by-copilot
independent_check: tests/auth-refresh.spec.ts
validation_sha: def456
required_checks_passed: true
human_review_complete: true
merge_rules_satisfied: true
rollback: disable-review-new-pushes
Common mistakes
- Assuming every push triggers a re-review without enabling Review new pushes.
- Treating an auto-resolved comment as a passing test or approval.
- Accepting a validation result produced for an older head SHA.
- Letting zero open Copilot threads bypass Code Owners, CI, security, or deployment rules.
- Keeping an inaccurate generated commit message because it sounds plausible.
- Applying GitHub's aggregate experiment results as a cost or quality promise for one repository.
Building something? Turn your product page into a show people want to watch with PromoFast—hosted, embeddable, and ready to export.
FAQ
Will pushing a fix automatically close the comment?
Only after Copilot re-reviews the pull request. Request the re-review manually, or enable automatic reviews for new pushes in the repository ruleset.
Does a resolved Copilot conversation count as approval?
No. Conversation resolution, review type, approval assessment, and whether a Copilot approval counts toward merge requirements are separate states.
Can Lite review now run tests?
GitHub says Copilot code review can use a broader set of shell tools, including builds and tests, behind its agent firewall. You should still require your own named CI checks on the exact head SHA.
Sources
- GitHub Changelog — Auto-resolution and analysis updates in Copilot code review: https://github.blog/changelog/2026-09-11-auto-resolution-and-analysis-updates-in-copilot-code-review/
- GitHub Docs — Using GitHub Copilot code review: https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review
- GitHub Docs — About GitHub Copilot code review: https://docs.github.com/en/copilot/concepts/agents/code-review
Originally published on IndieSeek.
Top comments (0)