Fine Grained Code Review Support

Describe the feature or problem you’d like to solve

PRs have a really nice way of leaving approvals, change requests, comments, and marking comments as resolved. gh cli does not appear to support comments on PRs

Proposed solution

CLI could allow commenting on a commit, filename, and line number, and it could allow retrieving all comments on all changes in a commit.

Additional context

This likely will need support from GH API -- There's comments on PR issues in general (https://developer.github.com/v4/object/pullrequest/) and comments for reviews: https://developer.github.com/v4/object/pullrequestreviewcomment/

this is on our roadmap! but we hadn't opened an issue for it yet, so thank you~

we wanted to do some designs up front and see what made the most sense; we only have some hand-drawn prototypes so far.

personally i was interested in something kind of like git add -p where you could page through comments/suggestions and take an action on each one. i'm curious what people think about that level of interactivity.

We've experimented with various flavors of this. For awhile we used git appraise, which has a CLI along the lines described by OP. We found it basically unusable, to the point where it was having a chilling effect on code review.

I prototyped a frontend which allowed you mark up a diff to leave comments, and that seemed fairly promising. The workflow ends up being similar to a the format-patch + email review workflow, except you do it all locally. The syntax I arrived on was using '>' as a prefix character for new comments, and something else (don't remember) for putting existing comments inside the patch, in context.

The only real issue I had was that emacs tries to be helpful with edited patch files to the point of breaking them when you try to add comment metadata. A derived mode to disable this feature fixed it.

Ultimately we chose to go back to github PR's rather than try to tool our way around it. The reason we were using it in the first place is because it gave us a way to digitally sign review comments; this would be a very attractive feature of any CLI-driven review workflow.

(also: Hi Nate! Thanks for making something great!)

Interactivity is nice but not needed for MVP. JetBrains etc can provide the interactivity using the cli hooks I'd suspect. Interactivity is a good v2 feature though I think

I prototyped a frontend which allowed you mark up a diff to leave comments, and that seemed fairly promising. The workflow ends up being similar to a the format-patch + email review workflow, except you do it all locally. The syntax I arrived on was using '>' as a prefix character for new comments, and something else (don't remember) for putting existing comments inside the patch, in context.

What about the reverse? Quote the entire patch file, and have people insert their comments without the quote marks. That will be familiar for anyone used to reviewing patches by email, and the > prefix on every line should prevent editors from attempting to fiddle with the patch.

I've renamed this as we have since added gh pr review (pending release) for adding a top level approve, request changes, or comment review on a given pr.

However, we did not include an affordance for line comments.

@vilmibm

Hey @vilmibm, stumbled across this issue after realizing that gh is getting improvements - awesome!

I just wanted to point out a project I made a while back called re that has a workflow for line by line review comments:

https://github.com/jordanlewis/re

I find it at least medium usable. It has a workflow that's half add -p inspired, but mostly uses a modified diff format that allows you to leave inline comments, right from an ordinary git diff that's available in a buffer.

Please feel free to take ideas from that project if you find it appealing!

What about the reverse? Quote the entire patch file, and have people insert their comments without the quote marks. That will be familiar for anyone used to reviewing patches by email, and the > prefix on every line should prevent editors from attempting to fiddle with the patch.

I strongly cosign this suggestion!

@vilmibm

Hey @vilmibm, stumbled across this issue after realizing that gh is getting improvements - awesome!

I just wanted to point out a project I made a while back called re that has a workflow for line by line review comments:

https://github.com/jordanlewis/re

I find it at least medium usable. It has a workflow that's half add -p inspired, but mostly uses a modified diff format that allows you to leave inline comments, right from an ordinary git diff that's available in a buffer.

Please feel free to take ideas from that project if you find it appealing!

Thanks

What about an option take a diff (e.g., the current local changes) and open the GitHub website with an in-progress review where the diffs have been turned into suggestions, so that one can edit it there and add comments to the proposed changes? Currently, I often find my self editing code locally and then copying the changes manually into the web interface.

Been review a lot of code lately. Browser sometime just struggles to render all the files. And even with the new navigation tool, still tricky to jump around files.

My ideal workflow:

gh pr review --diff #1
view diff in vim
a plugin action to run file.viewed
a plugin action to comment on current line in a split window.
a plugin action to review all comments and submit review

@jackieli-tes

@jackieli-tes If you are using neovim I can recommend https://github.com/pwntester/octo.nvim which is a plugin that is powered by gh.

@jackieli-tes

@jackieli-tes If you are using neovim I can recommend https://github.com/pwntester/octo.nvim which is a plugin that is powered by gh.

it look awesome! am definitely giving it a try.

@chadfurman

@chadfurman @adonh @silicakes @pppp606 @kesar @mislav @mullr @jordanlewis @vilmibm @silby @joshtriplett @danobi

We have implemented extension https://github.com/agynio/gh-pr-review. Feel free to use and share if you need anything!

Command to install: gh extension install Agynio/gh-pr-review
Paper: https://agyn.io/blog/gh-pr-review-cli-agent-workflows

I opened #12396, which was closed as a duplicate of this issue, so I’m adding the concrete CLI proposal here.

My main use case is adding inline PR comments without dropping to gh api or the web UI.

Proposed UX:

gh pr comment 123 --body "Consider optional chaining here" --path "src/utils.ts" --line 42

Possible flags:
• --path / -p: file path in the diff
• --line / -L: line number or range
• --side / -s: LEFT or RIGHT, default RIGHT

The key DX improvement would be auto-resolving the PR head commit SHA, so users do not need to look it up manually.

More details can be founded here #12396

feat: add --author, --all, and --commit flags for agent triage workflows

This would be extremely helpful for understanding PRs written by AI coding agents.

@SergiuSavva

@SergiuSavva take a look on https://github.com/agynio/gh-pr-review, we made an extension for gh where you can add inline PR comments

Use case

I ran into this while trying to automate PR code review from GitHub Actions. The goal was to create inline review comments on specific changed lines/ranges, similar to what GitHub's review UI supports.

Current `gh` behavior

With gh 2.83.2, gh pr review appears to support only review-level actions:

--approve
--comment
--request-changes
--body / --body-file

I could not find a native high-level way to provide path, line, side, start_line, or position to gh pr review for inline review comments.

Request

A native command such as one of these would be very useful:

gh pr review-comment 123 --path app/file.ts --line 42 --body '...'
gh pr review 123 --comment --path app/file.ts --line 42 --body '...'

Ideally it would support:

single-line comments
multi-line ranges
left/right diff side
creating a submitted review with one or more inline comments
clearer validation errors when GitHub rejects the coordinates

Update 2026-05-07 - Working workaround

I found a working way to create inline PR review comments with gh api with the pull request reviews endpoint:

gh api repos/OWNER/REPO/pulls/PULL_NUMBER/reviews \
  --method POST \
  --input /tmp/review.json

Where /tmp/review.json includes:

{
  "commit_id": "<HEAD_SHA>",
  "event": "COMMENT",
  "body": "Review body",
  "comments": [
    {
      "path": "path/to/file.ts",
      "line": 42,
      "side": "RIGHT",
      "body": "Inline comment body"
    }
  ]
}

This creates a submitted PR review object with grouped inline comments on the changed lines.

Update 2026-05-08 - Direct comment endpoint also works

After the GitHub incident mentioned in #13358 was resolved, I re-tested the direct pull request comments endpoint and it now works too. These gh api approaches created inline comments successfully:

Single-line inline comment:

gh api repos/OWNER/REPO/pulls/PULL_NUMBER/comments \
  --method POST \
  -f body='Inline comment body' \
  -f commit_id='<HEAD_SHA>' \
  -f path='path/to/file.ts' \
  -F line=42 \
  -f side='RIGHT'

Multi-line range comment:

gh api repos/OWNER/REPO/pulls/PULL_NUMBER/comments \
  --method POST \
  -f body='Inline comment body' \
  -f commit_id='<HEAD_SHA>' \
  -f path='path/to/file.ts' \
  -F start_line=40 \
  -f start_side='RIGHT' \
  -F line=42 \
  -f side='RIGHT'

Legacy diff-position comment also worked:

gh api repos/OWNER/REPO/pulls/PULL_NUMBER/comments \
  --method POST \
  -f body='Inline comment body' \
  -f commit_id='<HEAD_SHA>' \
  -f path='path/to/file.ts' \
  -F position=10

So the REST API workaround is viable both for creating a submitted review with grouped inline comments (/reviews) and for creating individual inline comments (/comments). Native gh pr review / gh pr comment support would still be useful because the CLI could resolve the PR head SHA and diff coordinates automatically.

Navigation Menu

Repository navigation

Fine Grained Code Review Support #359

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

13 remaining items

Use case

Current `gh` behavior

Request

Update 2026-05-07 - Working workaround

Update 2026-05-08 - Direct comment endpoint also works

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Fine Grained Code Review Support #359

Description

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

Activity

vilmibm commented on Feb 12, 2020

mullr commented on Feb 12, 2020

chadfurman commented on Feb 12, 2020

joshtriplett commented on Feb 12, 2020

vilmibm commented on May 14, 2020

jordanlewis commented on Jun 6, 2020

silby commented on Apr 23, 2021

collinalexbell commented on Jul 21, 2021

chdoc commented on Sep 12, 2021

jackieli-tes commented on Mar 30, 2022

samcoe commented on Apr 2, 2022

jackieli-tes commented on Apr 2, 2022

13 remaining items

Benkovichnikita commented on Dec 7, 2025

SergiuSavva commented on Apr 5, 2026

RyanJarv commented on Apr 16, 2026

Benkovichnikita commented on Apr 25, 2026

xoelop commented on May 6, 2026

Use case

Current gh behavior

Request

Update 2026-05-07 - Working workaround

Update 2026-05-08 - Direct comment endpoint also works

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Current `gh` behavior