Copilot coding agent cannot resolve PR review threads

[ThePlenkov]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Copilot Cloud Agent

Body

Summary

When I ask Copilot coding agent (@copilot /act) to finish a pull request — fix CI, address review comments, and resolve review conversations — the agent cannot complete the resolve step through any supported, documented path. The product behaves as if “resolve threads” is optional UI polish, but for teams using required conversation resolution and agent-driven /act workflows it is a core merge-readiness action.

This is not a model “forgetting” to click Resolve. It is structurally blocked by token permissions and the read-only GitHub MCP surface exposed to the agent.

What I expect

On @copilot /act on an existing PR, the agent should be able to:

1. Read review threads (all bots: Copilot, Gemini, Cubic, etc.)
2. Push fixes to the PR branch (this works)
3. Reply in thread when needed
4. Resolve conversation on each handled thread (including outdated duplicates)
5. Report open threads = 0 before claiming merge-ready

That matches how humans use “Resolve conversation” on GitHub and how branch protection / required resolution works.

What actually happens

1. GitHub MCP is read-only (~33 tools)

Agent log shows github-mcp-server starts with tools like pull_request_read, actions_list, get_file_contents, etc. — but not:

• pull_request_review_write (which includes resolve_thread / unresolve_thread)
• add_pull_request_review_comment

So the agent cannot resolve via MCP, despite docs describing pull_request_review_write → resolve_thread with PRRT_… thread IDs.

get_review_comments returns threads without id (PRRT_…), so even workarounds that need thread IDs cannot chain through MCP alone.

2. GITHUB_TOKEN in the agent cannot run resolveReviewThread

Using gh api graphql with GITHUB_TOKEN fails with insufficient permissions (not firewall — allowlist is configured).

The agent can push commits to its branch but cannot mutate review thread state. So “resolve” and “write code” are oddly split across different permission models.

3. Workarounds are unreasonable

• Playwright / browser: GitHub UI is often ERR_BLOCKED_BY_CLIENT in the agent environment — not a serious API.
• Separate Agents secret PAT (OPENADT_GH_PR_TOKEN with Pull requests: Read and write): works, but why should every repo admin mint and store a PAT so the official agent can click the equivalent of “Resolve conversation”?
• Manual resolve by humans: defeats the purpose of @copilot /act.

4. Agent gives up or marks /act “done” incorrectly

Sessions end with:

• Code fixes pushed (good)
• 0 resolve_thread calls
• Many threads still open
• Checkbox “resolve conversations” marked done anyway, or entire /act aborted as “blocked”

Evidence (public repro context)

• Repo: open-source PR workflow with multiple bot reviewers (20+ threads)
• Copilot agent sessions on GitHub.com (@copilot /act)
• Documented skill requiring resolve; agent loads skill but platform cannot execute resolve

Ask / product feedback

1. Ship write PR review tools on the default Copilot coding agent MCP (at least pull_request_review_write with resolve_thread), not only read-only pull_request_read.
2. Grant GITHUB_TOKEN (or a first-class agent token) permission to resolveReviewThread on PRs the agent is already allowed to push to — same security boundary, strictly scoped to that PR.
3. Return PRRT_… thread id in get_review_comments so resolve can work end-to-end without gh fallbacks.
4. Document the supported resolve path for @copilot on PRs — today it reads as if MCP + agent can do PR hygiene, but resolve is a dead end unless users add PAT secrets.

Why this matters

• Required conversation resolution on protected branches
• Agent /act skills that explicitly require “Resolve conversation” (not just reply in a top-level PR comment)
• Multi-bot reviews (duplicate threads on the same issue) where resolve is the only way to clear noise

Pushing code without resolving threads leaves PRs in a false “done” state and forces humans to clean up what the agent was asked to do.

---

Happy to share redacted agent session logs (tool list, GraphQL errors, thread counts) if useful. Thanks for considering this as a product gap, not user error.

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

[Farshidbagheri]

I agree that this is a real workflow gap, not just a prompt-quality issue.

The important distinction is that “fixing the code” and “making the PR merge-ready” are not the same thing in repositories that require conversation resolution. If required conversation resolution is enabled, then unresolved review threads are part of the merge gate, just like failing CI or missing approvals.

From an end-user perspective, an agent asked to “finish this PR” should probably treat the PR as incomplete until all of the following are true:

CI/checks are passing
requested code changes are pushed
review comments are answered where needed
handled review threads are resolved
remaining open threads are reported accurately

Right now, if the agent can push commits but cannot resolve the corresponding review threads, the workflow ends in a half-complete state: the code may be fixed, but the PR is still not merge-ready.

The clean product solution would be a first-class, narrowly scoped PR review-thread capability for the agent, rather than requiring every repository admin to create and maintain a separate PAT secret.

A safe design could be something like:

Allow the agent to resolve/unresolve review threads only on the PR it is currently acting on,
only after it has pushed or proposed a relevant fix,
and always leave an auditable trace in the agent session log.

That would preserve the security boundary while matching the actual PR workflow.

I also think the API/tooling surface should expose the necessary thread identifiers end-to-end. If a tool can list review conversations but does not return the PRRT_... thread id needed to resolve them, then the workflow is effectively read-only even if a documented GraphQL mutation exists elsewhere.

A useful minimal capability set for this workflow would be:

list review threads with thread ids
reply to a review thread
resolve a review thread
unresolve a review thread if needed
report unresolved thread count before marking the task complete

Until that exists, the agent should probably avoid saying the PR is “done” or “merge-ready” when unresolved threads remain. A safer final status would be something like:

Code fixes were pushed, but I could not resolve review threads because this action is not available to the agent. N conversations remain open and require human action.

That would at least prevent the false-done state.

So I would frame this as a product/API consistency issue:

• GitHub already has a concept of resolved PR review threads.
• Protected branches can require conversation resolution.
• Copilot coding agent can be asked to address PR feedback.
• But the agent currently lacks a complete, documented, permissioned path to clear the review-thread state.

For teams using required conversation resolution, resolving handled threads is not cosmetic. It is part of merge readiness.

[ThePlenkov]

and again! funny thing is - if you ask Codex cloud agent or Claude cloud agent or any other cloud agent with Github app integration - they can do this easily, but not Copilot itself =)

[Farshidbagheri]

Exactly — that comparison makes the gap even clearer.

If other cloud agents with GitHub App integration can resolve PR review conversations, then the limitation is probably not inherent to “AI agents” or automation in general. It is more specifically about the permission/tooling surface exposed to Copilot coding agent.

That also supports the main product point: Copilot can already participate in the PR workflow by pushing code changes, but it does not seem to have the complete PR-review capability needed to finish the workflow when required conversation resolution is enabled.

So the missing piece is not just “better reasoning”; it is a first-class, permissioned path for Copilot to:

• read review threads with stable thread IDs,
• reply where needed,
• resolve handled threads,
• and report remaining unresolved conversations accurately.

If this framing captures the issue well, feel free to mark the answer so others following the same Copilot PR workflow limitation can find the main explanation quickly.

[ThePlenkov]

Ideally I would add also ability to react like +1 -1 or with other available emojis. We could build also nice flow around it

[Farshidbagheri]

Glad the explanation helped. If this answered the original question, could you please mark my reply as the accepted answer? That would help future readers find the solution more easily.

[ThePlenkov]

well i think this discussion must stay unaswered unless some actionable item is created - like a backlog item in a roadmap

[ThePlenkov]

One more observation! in case if I tag @claude ( as copilot agetn https://docs.github.com/en/copilot/concepts/agents/anthropic-claude ) in my comment and ask claude to fix it. Then claude can do everything! resolve threads comment back. So it's really crazy - copilot cannot but copilot via claude can..