Copilot code review says "One or more issues must be addressed" but reports no findings

[glen-84]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Copilot Code Review

Body

What happened

Copilot code review posted an overview whose verdict says issues must be addressed before approval, but the same overview reports no findings, and the review has no inline comments. There is nothing to act on.

The review was the first Copilot review of a small PR (6 files, +126/−12). The verdict part of the overview:

### 🔵 Needs a closer look

One or more issues must be addressed before approval.

**Review effort:** Lite
**Findings:** None

The body has no Open or Previously missed section. The rest of it is the "What changed in this PR" summary.

Expected behavior

• If Copilot found an issue, the overview or an inline comment says what it is.
• If it found none, the verdict shouldn't say that issues must be addressed. If "Needs a closer look" only means Copilot didn't judge the PR ready to approve, the overview should say so, and say why.

Other reports

People who parse Copilot reviews in their own tooling have recorded the same mismatch between the verdict and the findings count:

• Copilot review-body drift signal fires on a clean no-findings review cboone/agent-harness-plugins#491: the same sentence with Findings: None at Lite effort, on a re-review whose one earlier finding was resolved.
• copilot-signals: detect body-only findings in ccr-overview-v2 reviews dgowrie/claude-workflows#132: the same verdict with Findings: None on first reviews, where the only concern is one sentence under the heading.
• Request Copilot code review at Balanced effort when a Lite review can't approve a large diff Morrison-Lab/ai-config#3967: every Lite review of a PR with 560+ changed lines ended at this verdict with no findings. Diff size doesn't explain this case, since the PR above is small.

Drafted by Claude (Anthropic AI assistant).

[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. ⭐

[JGronholz]

🔵 is the worst. This is the most specific one I've ever seen.

The real problems:

1. "Moderate defects" should remain 🟠 until they are resolved.
   • Current severity should not mask previous severities.
2. A large quantity of minor defects 🔵🔵🔵 is a moderate defect 🟠.
   • "Recurring defect patterns"
3. This is a summary (of a previous summary (with actionable findings (that can't be attached to specific lines of code))).
   • Defects that are separate in turn X should remain separately summarized in subsequent turns.
   • Actionable becomes antlAiobec

See here: https://github.com/orgs/community/discussions/209944

[JGronholz]

Not found unless explicitly searched for:

[iamyakay]

The API confirms the mismatch in your example. Review 5425790211 has state COMMENTED, its comments endpoint returns an empty list, and the body contains no specific concern beyond the generic “issues must be addressed” sentence. There isn't an actionable finding hidden in that review's inline comments.

GitHub's [documentation](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/use-code-review) says the overview includes an approval assessment separately from the actual approval. That distinction allows “no findings, but not ready to approve,” but the wording needs to explain why. Saying there are issues to address without identifying any doesn't communicate that.

The linked reports also show why tooling can't simply treat Findings: None as approval. In #132, a concrete concern appeared in the body despite that count. Your review has no equivalent concern, so those cases need different handling.

I'd treat this as an inconsistent review result requiring human review, rather than inventing a fix or repeatedly requesting Lite reviews. GitHub would need to confirm whether a finding was omitted or the wrong verdict text was generated. Either way, the overview should identify the issue or explicitly say that no issues were found and explain why approval was withheld.

[slyyr]

I think the important distinction here is between a review's overall verdict and the actual findings that explain that verdict.

If the review says that issues must be addressed but reports no findings and provides no inline comments, the author has no actionable information to work with.

I'd suggest checking whether the review contains a separate summary, hidden or collapsed findings, or a previous review whose unresolved status is being carried forward. If none of those explains the verdict, this looks like a consistency problem in the generated review output.

A useful regression test would cover at least three cases:

• Findings exist and the verdict requests changes.
• No findings exist and the verdict indicates that no actionable issues were identified.
• A previous finding was resolved and a subsequent review confirms that resolution.

The system should also distinguish a recommendation for additional human review from an actual finding that blocks approval.

That distinction would make the review output more reliable for both developers and automation that consumes the verdict.