Copilot code review: Previously missed findings should be posted as inline comments

[dictav]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Copilot in GitHub

Body

The new Previously missed section is easy to overlook because those findings are shown only in the overview comment and are not posted as inline review comments.

These are still actionable, unresolved findings, so developers who review unresolved conversations or inline comments can easily miss them.

Please either:

• post Previously missed findings as inline comments, or
• provide a setting to enable inline comments for them.

At minimum, Previously missed findings should be surfaced as prominently as Open findings.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[paulmedynski]

I agree with the above, and would also include "Suppressed findings". I would like to be able to promote any/all feedback that Copilot has to individual feedback thread comments. As it is currently, trying to find all feedback is difficult.

[Sweety717]

I agree that the distinction between “finding exists” and “finding is surfaced where the developer is already working” matters a lot.

For automated PR review, I’d treat findings as part of a lifecycle:

detected → surfaced → acknowledged → resolved/suppressed

If a finding only exists in an overview summary, it can easily disappear from the developer’s normal review flow.

Inline comments make the finding actionable because they preserve the connection between the issue and the exact code location.

It would also be useful to distinguish new findings, previously missed findings, and suppressed findings while keeping all three accessible from the PR review.

[jef-gomez-01]

I've been experiencing this as well. Copilot reviews after the first iteration typically contain multiple items being introduced in "Previously missed" (they were never previously reported), and none of them include links to a comment that I can address/decline. This causes an accumulation of findings lacking means to resolve them; effectively paralyzing the Copilot review.

[Sweety717]

I’ve seen a similar issue. The “previously missed” distinction becomes especially problematic when a finding appears without a clear location, context, or way to resolve or dismiss it.I think each finding should remain actionable across review iterations , ideally with the affected code location, evidence for why it matters, and a clear way to confirm whether the issue was actually resolved. Otherwise, the review history becomes harder to trust as the PR evolves.

[kendistiller]

I’d also like to share an observation from working with external AI agents and Copilot. The way these issues are currently presented is particularly confusing to AI agents. Claude (Opus and Fable) and Grok have all repeatedly overlooked review comments and even pushed back on them, incorrectly asserting that the issues had already been resolved.

Given how heavily engineers now rely on AI agents in their development workflows, I think it’s increasingly important to make review feedback as clear, unambiguous, and agent-friendly as possible.