Repository navigation
Add native support for inline PR review comments and resolvable review threads #12273
Description
Link to issue for design submission
#359
(Original long-standing request for inline PR review support)
This proposal addresses the missing ability for gh to display and interact with
inline pull request review comments and review threads.
Proposed Design
The goal is to introduce native support in gh for viewing and interacting with
line-level PR review comments, including:
- displaying inline review threads,
- filtering unresolved review comments,
- replying to review threads,
- and resolving review conversations.
Today, users or AI agents must manually chain several GitHub API calls:
list reviews → list threads → list comments, and filter needed fields using jq skipping urls/hashes and etc that don't add any value. For AI agents such tooling can cause multiply step overhead, exploding context and facing the errors building complex GraphQL queries.
Proposed additions
- Introduce a new command group
gh pr review view <pr> - Support core filters
--unresolved— show only unresolved review threads--reviewer <login>— filter by reviewer--tail <n>— limit number of threads returned per file
- Support actions on review threads
gh pr review comments reply <pr> --thread-id <id> --body <text>gh pr review threads resolve <pr> --thread-id <id>
- Provide a stable LLM-readable output format that returns a compact, deterministic schema suitable for automation and LLM-based tools.
Extension
A functioning prototype of this workflow already exists as a community extension:
👉 https://github.com/agynio/gh-pr-review
gh extension install agynio/gh-pr-review
Example Before vs After:
Task is to get unresolved threads filtered by a reviewer and tail size 2 (last two comments for each).
- Chain
gh api+jq
gh api graphql \
-f query='
query($owner:String!, $repo:String!, $number:Int!, $login:String!) {
repository(owner:$owner, name:$repo) {
pullRequest(number:$number) {
reviewThreads(first:100) {
nodes {
id
isResolved
comments(last:10) {
nodes { id author { login } body }
}
}
}
reviews(first:100, states:[CHANGES_REQUESTED]) {
nodes { author { login } state }
}
}
}
}' \
-F owner=owner -F repo=repo -F number=42 -F login=octocat \
| jq '
.data.repository.pullRequest
| {
threads: (
.reviewThreads.nodes
| map(select(.isResolved==false)
| .comments.nodes
| map(select(.author.login=="octocat"))
| (.[-2:] // []))
),
reviews: (.reviews.nodes | map(select(.author.login=="octocat")))
}'
gh pr-reviewextension
gh pr-review review view 42 -R owner/repo \
--reviewer octocat --states CHANGES_REQUESTED \
--unresolved --tail 2 --include-comment-node-id
Activity
github-actions commentedon Dec 8, 2025
Thank you for your issue! We have categorized it as a feature request, and it has been added to our backlog. In doing so, we are not committing to implementing this feature at this time, but, we will consider it for future releases based on community feedback and our own product roadmap.
Unless you see the help wantedContributions welcome
label, we are not currently looking for external contributions for this feature.
If you come across this issue and would like to see it implemented, please add a thumbs up! This will help us prioritize the feature. Please only comment if you have additional information or viewpoints to contribute.
Benkovichnikita commentedon Dec 8, 2025
Hey @williammartin! We added an extension as you proposed! If you have any thoughts, let us know.
BagToad commentedon Dec 8, 2025
@Benkovichnikita could you please add a design proposal to your issue that follows our contribution guidelines?
We typically only encourage design proposals for issues where we have requested it - this is a quote from our guidelines:
Please note that #359 has neither labels.
Currently, this issue seems like a duplicate of #359 with some added behavior descriptors and command line flags, but we're missing what happens with those behaviors and command line flags as would be typical in a full design. In particular, there's no consideration in the current issue with regard to any interactive flows and what those will look like. This need to see what happens is true for non-interactive behavior as well.
As an application used by agents, human users, and other autonomous applications, we must strike a balance between all these user types. We also have accessibility compliance obligations to uphold in all
ghexperiences, like how will the output be perceived by a screen reader, so some considerations there are typically required in a design of this magnitude.With design proposals, we're looking for a detailed write-up of the command set that includes mock-ups of all the different behavior paths and edge cases. We provide several resources in our contribution guidelines that we expect to be leveraged here including a google doc template for creating design proposals and detailed design guidance for CLI output and ergonomics.
With a real design proposal added to this issue using the materials provided and respect given to our contributing guidelines, I'd be happy to leave this issue open for a review by the core maintainers when we have the capacity to do so. Please let us know if you are interested in contributing in this way, following our processes and using the design materials as described by our guidelines.
Benkovichnikita commentedon Dec 9, 2025
@BagToad
Thank you for the clarification and for pointing to the contribution guidelines.
To be transparent about my intention: I did not mean to request or initiate a full design proposal from the core team. I simply wanted to provide visibility to the community that there is a working solution today for people who search for inline review thread support in
gh. We regularly see users asking for this functionality in various channels, and many are not aware that an extension can fill this gap.I understand that design proposals should only be created for issues that have the needs-design and help-wanted labels. Since this issue does not have those labels, I did not want to imply that I am proposing work for the team or that this should become a formal design effort.
My intent was only to:
If a future design discussion becomes relevant, I am happy to contribute following your process and templates. For now, I simply wanted to share information that might be useful to GitHub CLI users who run into this limitation.
BagToad commentedon Dec 9, 2025
Thank you for clarifying @Benkovichnikita. With all that in mind, I'll close this out as a duplicate of #359.