Copilot’s new review overview includes findings you won’t see inline

GitHub’s September 18 update to Copilot code review adds a useful distinction to the review overview: an issue can be newly discovered without being newly introduced. The update is generally available, and one detail deserves attention from teams that summarize reviews or send findings into other tools. Previously missed findings appear in the overview, not elsewhere on the pull request.

That changes what a complete reading of the review requires. A developer who checks only inline comments, or an integration designed only around those comments, can overlook findings that Copilot puts in the overview. Before changing the automation, understand what the new groups mean.

One section contains details that exist nowhere else

Previously missed is a new category within the overview, alongside Open and Resolved since last review. It contains issues already present in the existing changes but discovered during a subsequent Copilot review. GitHub says it includes their exact details because they are not posted elsewhere on the pull request.

That makes the overview more than a convenient index. For this category, it is the place where the substantive information lives. Following links from an exported list of inline discussions will not recover an entry that was never part of that list.

The overview also distinguishes these late discoveries from issues introduced by a new commit, which can receive a “new” label under Open. That distinction needs to survive when information leaves GitHub.

Read the overview before handing off the review

For a person reviewing a pull request, the immediate adjustment is small: read the overview alongside the inline discussion. If Previously missed contains a relevant issue, inspect the affected code and decide how to address it rather than waiting for a separate inline comment to arrive.

For teams that turn AI findings into work items, the adjustment depends on how the current process collects them. Our recommendation is to trace one reviewed pull request from GitHub to its destination. Does a person copy the overview into a handoff? Does a script collect only inline comments? Does an internal summary include the details of previously missed findings, or only a count?

The source does not specify a stable API representation, webhook behavior, or export format for these groups. Inspect the data your integration actually receives before changing a parser. A visible improvement to a product screen does not tell you which fields an existing integration will obtain.

When adapting a summary, preserve the finding’s location and enough detail for a developer to investigate it. Keep an unresolved overview finding visible in the handoff even if it has no corresponding inline thread. That is workflow guidance, not a claim that GitHub has added a new task-management feature.

Separate late discovery from a regression

A subsequent review can find a problem that the earlier review missed. That should prompt investigation of the problem, but it should not automatically become evidence that the latest commit introduced a regression.

Consider a review handoff that lists everything first seen in the latest review as “new defects.” With the updated overview, that label would combine two different events: a defect added in new code and an existing defect detected later. Anyone deciding which change to revert would then need to reconstruct the distinction.

Use the source category to guide that investigation, then check the relevant diff and behavior. If the overview says Previously missed, look back through the existing changes before assigning the cause to the newest commit. Copilot’s grouping helps direct attention; the code and test evidence still establish what happened.

This is different from the open-thread reporting question in our earlier explanation of Copilot auto-resolution. That update reduced manual thread cleanup after fixes. The new overview also gives reviewers a place to find issues that never received a separate inline comment.

Test whether the handoff preserves the information

The integration question is whether the destination contains the information a developer needs, not whether the export completed successfully. A chat digest, issue tracker, or internal dashboard can receive a valid response while omitting the section that matters.

Use the following acceptance checks when testing your intake. These are proposed checks, not measurements of a GitHub integration.

Scroll sideways to see all 3 columns.

Input to inspect	What the destination should preserve	What would make the handoff incomplete
A Previously missed entry in the overview	The issue details and a route back to the source	A count without the description
An issue discovered in existing changes	Its classification as a later discovery	Relabeling it as introduced by the latest commit
An overview updated after another review	The current content and a record of when it was collected	An earlier snapshot presented as current
A finding without an inline discussion	A visible item that someone can investigate	Filtering it out because no inline thread exists

The last case is worth checking explicitly. An integration may use an inline-comment identifier as its admission rule: no identifier, no item. That is a possible design limitation to test for, not a documented defect in GitHub’s APIs. Likewise, avoid assuming that a new overview version always represents a new finding; otherwise the destination may create duplicate work each time the summary changes.

If your intake cannot yet carry these entries reliably, keep the overview link prominent and assign a person to read it. A manual step is a reasonable temporary solution when it closes a known information gap. Automating an incomplete handoff only makes the omission harder to notice.

The useful outcome is straightforward: someone receiving the handoff can find the issue, understand when it was discovered, and reach the source without having to guess which part of the pull request was omitted.

Source

GitHub: Copilot code review: An improved review experience, September 18, 2026. Product behavior above comes from this announcement. Integration and review recommendations are BaristaLabs guidance.