Pinned comments on pull requests, with REST and GraphQL support

[dgilman-perplexity]

🏷️ Discussion Type

Product Feedback

Body

Summary

Extend pinned comments to pull requests, with the same REST and GraphQL support that issues received in February 2026.

Pinned comments on issues shipped in February (changelog) and the API followed shortly after (PUT /repos/{owner}/{repo}/issues/comments/{comment_id}/pin, pinIssueComment mutation). The API docs for the mutation currently state: "Comment pinning is not supported on Pull Requests." This proposal asks for that restriction to be lifted.

Problem

The conversation tab on a long-lived pull request accumulates bot comments, review summaries, scope notes, and merge-queue status. The single most important piece of context for a reviewer, such as "which teams still need to approve" or "this PR was restacked, the earlier approval does not cover the new commits," is usually posted by a bot as a normal comment and scrolls out of view as the thread grows.

Today the workarounds are:

• A "sticky" comment that the bot edits in place. This keeps one comment rather than many, but it stays wherever it was first posted in the timeline and gets buried.
• Writing status into the PR description. This works but means a bot is editing author-owned text, and it does not fit well when several bots each have status to show.
• A check run with a rich summary. This lands in the merge box and Checks tab, not at the top of the conversation where reviewers read first.

None of these keep an authoritative status comment at the top of the conversation.

Proposal

1. Allow a comment on a pull request to be pinned to the top of the Conversation tab, exactly like the existing issue behaviour (one pinned comment per PR, shown above the timeline, with a pinned/unpinned timeline event).
2. Make the existing endpoints work for PR comments:
   • PUT /repos/{owner}/{repo}/issues/comments/{comment_id}/pin and the matching DELETE
   • pinIssueComment / unpinIssueComment GraphQL mutations
   • isPinned, viewerCanPin, pinnedAt, pinnedBy on IssueComment reflecting the real state for PR comments
3. Gate it with the same permission as issues (issues: write, or pull_requests: write if that is the more natural fit for PR comments), so a GitHub App can pin its own status comment when it creates it and no human has to do it by hand.

Since issue comments and PR conversation comments already share the same IssueComment type and REST endpoints, this feels like a scope change rather than a new feature.

Why the API matters

The main consumer of this feature on PRs is automation, not people. Ownership and approval bots, merge-queue bots, and release tooling already maintain a single status comment per PR. With a pin API they could keep that comment at the top with one extra call after posting. Without the API, a UI-only version would help far less, because nobody is going to manually pin a bot comment on every PR.

Prior requests

• The announcement thread for pinned comments on issues has the top-voted reply asking for PR support and an API: https://github.com/orgs/community/discussions/186435#discussioncomment-15709978 (acknowledged by GitHub staff in June 2026 as noted internally)
• A broader proposal that bundles PR pinning with reviewer focus areas: https://github.com/orgs/community/discussions/175607

This proposal is intentionally narrower: just pinned comments on PRs, plus the API, matching what issues already have.

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