Title: Copilot Code Review generates new comments on every push, creating an endless fix-push-review loop

[mbenzakis]

Select Topic Area

Product Feedback

Copilot Feature Area

Copilot in GitHub

Body

Problem

When Copilot Code Review is enabled on a repository, every push to a PR triggers a full re-scan of the diff. This means that after fixing Copilot's comments and pushing, Copilot generates new comments on code that was already in the previous diff but wasn't flagged before. This creates an endless loop:

1. Copilot reviews PR → generates N comments
2. Developer fixes all N comments → pushes
3. Copilot re-reviews → generates M new comments on unchanged code
4. Developer fixes M comments → pushes
5. Copilot re-reviews → generates K new comments again
6. Repeat...

Real-world experience (today)

I had two PRs open today:

• PR A: ~9 changed files (Python data pipeline tools)
• PR B: ~9 changed files (Python log collection utilities)

Here's what happened with PR A:

Round | Push | New Copilot comments | Action -- | -- | -- | -- 1 | Initial PR | 10 comments | Fixed all 10, pushed 2 | Fix push | 6 new comments | Fixed all 6, pushed 3 | Fix push | 4 new comments | Fixed all 4, pushed 4 | Fix push | 2 new comments | Fixed both, pushed 5 | Fix push | 2 more new comments | Gave up

Total: 5 rounds of review for a single PR. Each round took 15-30 minutes. The same pattern repeated on PR B.

Quality of comments

The bigger issue is the signal-to-noise ratio. Out of ~24 total comments across all rounds:

• ~3 were genuinely useful (e.g., UnboundLocalError due to uninitialized variable, missing function arguments causing crash)
• ~21 were low-value (e.g., error message wording "not a list" should be "not a dict", logger.error(exc_info=True) vs logger.exception(), naming suggestions, comment typos)

The severity labels (Medium/High) don't accurately reflect actual impact. A comment about error message wording gets "Medium" while a real crash bug also gets "Medium".

Expected behavior

1. First review should catch everything — If Copilot can find an issue on round 3, it should find it on round 1.
2. Fix pushes should only verify fixes — After a fix push, Copilot should confirm the previous comments are addressed, not scan for entirely new issues.
3. At minimum, provide an option to limit re-review scope to "verify previous comments only."

Additional friction: VS Code Copilot ≠ Web Copilot

I use VS Code Copilot (Claude Opus 4.6) to fix the Web Copilot Review comments. These are completely separate systems with no shared context:

• VS Code Copilot doesn't know what Web Copilot flagged
• Web Copilot doesn't know what VS Code Copilot fixed
• There's no way to run the same checks locally before pushing

If VS Code Copilot could run the same review rules before push, the loop would be eliminated entirely.

Suggestions

1. Limit re-review scope: After a fix push, only verify that previous comments are addressed. Don't generate net-new comments.
2. Better severity classification: Distinguish between "will crash at runtime" (Critical) and "style/wording preference" (Info).
3. Allow filtering by severity: Let repository admins set a threshold (e.g., only show High and above).
4. Integrate with VS Code: Allow developers to run the same Code Review check locally before pushing.
5. Add a "stop reviewing" option: After the first review, let the PR author opt out of further automatic reviews.

Environment

• GitHub Enterprise Cloud
• Copilot Code Review enabled at organization level
• PRs with 9-10 changed Python files (~500-1000 lines of diff)
• VS Code with Copilot Chat (Claude Opus 4.6) used for fixes

Problem When Copilot Code Review is enabled on a repository, every push to a PR triggers a full re-scan of the diff. This means that after fixing Copilot's comments and pushing, Copilot generates new comments on code that was already in the previous diff but wasn't flagged before. This creates an endless loop:

Copilot reviews PR → generates N comments
Developer fixes all N comments → pushes
Copilot re-reviews → generates M new comments on unchanged code
Developer fixes M comments → pushes
Copilot re-reviews → generates K new comments again
Repeat...
Real-world experience (today)
I had two PRs open today:

PR A: ~9 changed files (Python data pipeline tools)
PR B: ~9 changed files (Python log collection utilities)
Here's what happened with PR A:

Round Push New Copilot comments Action
1 Initial PR 10 comments Fixed all 10, pushed
2 Fix push 6 new comments Fixed all 6, pushed
3 Fix push 4 new comments Fixed all 4, pushed
4 Fix push 2 new comments Fixed both, pushed
5 Fix push 2 more new comments Gave up
Total: 5 rounds of review for a single PR. Each round took 15-30 minutes. The same pattern repeated on PR B.

Quality of comments
The bigger issue is the signal-to-noise ratio. Out of ~24 total comments across all rounds:

~3 were genuinely useful (e.g., UnboundLocalError due to uninitialized variable, missing function arguments causing crash)
~21 were low-value (e.g., error message wording "not a list" should be "not a dict", logger.error(exc_info=True) vs logger.exception(), naming suggestions, comment typos)
The severity labels (Medium/High) don't accurately reflect actual impact. A comment about error message wording gets "Medium" while a real crash bug also gets "Medium".

Expected behavior
First review should catch everything — If Copilot can find an issue on round 3, it should find it on round 1.
Fix pushes should only verify fixes — After a fix push, Copilot should confirm the previous comments are addressed, not scan for entirely new issues.
At minimum, provide an option to limit re-review scope to "verify previous comments only."
Additional friction: VS Code Copilot ≠ Web Copilot
I use VS Code Copilot (Claude Opus 4.6) to fix the Web Copilot Review comments. These are completely separate systems with no shared context:

VS Code Copilot doesn't know what Web Copilot flagged
Web Copilot doesn't know what VS Code Copilot fixed
There's no way to run the same checks locally before pushing
If VS Code Copilot could run the same review rules before push, the loop would be eliminated entirely.

Suggestions
Limit re-review scope: After a fix push, only verify that previous comments are addressed. Don't generate net-new comments.
Better severity classification: Distinguish between "will crash at runtime" (Critical) and "style/wording preference" (Info).
Allow filtering by severity: Let repository admins set a threshold (e.g., only show High and above).
Integrate with VS Code: Allow developers to run the same Code Review check locally before pushing.
Add a "stop reviewing" option: After the first review, let the PR author opt out of further automatic reviews.
Environment
GitHub Enterprise Cloud
Copilot Code Review enabled at organization level
PRs with 9-10 changed Python files (~500-1000 lines of diff)
VS Code with Copilot Chat (Claude Opus 4.6) used for fixes

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

[luqiang21]

Exactly same experience. Why can't copilot generates all comments at once?

[mishra-punit]

Endless loop...If not in one attempt, then two to three should be enough. It is endless.

[ernestasdoingcode]

Looking forward for the change - it is counter-productive and our developers spend unnecessary time because of copilot's review over again on the same lines of code. It's major drawback for us.

[JavierArques-Emburse]

Same issue for my team. Is there any way to review all the code at once or limit the iterations?
It seems that every time we try to correct a copilot's comment, new and different comments appear, which takes up a lot of our time.