What do you want to change?
Add a way to reply to an existing inline review note from the session CLI.
hunk session comment add --reply-to <note-id> creates a reply to that note,
inheriting its anchor the way the TUI's R does.- The same field is available per entry in the
comment apply batch payload.
hunk session comment list --json reports the parent so a caller can
reconstruct a thread. SessionReviewNoteSummary already carries parentId,
so this may work already.- A call without
--reply-to behaves exactly as it does today.
Non-goals:
Why?
The TUI can reply to a review note, but this isn't exposed through the CLI, so
agents can't easily drive replies to comments.
In the TUI, R (hunk.review.replyToActiveNote) replies to the active note,
replies inherit the parent's code anchor, and they nest. From the CLI,
hunk session comment add takes --file, --old-line / --new-line,
--summary, --rationale, --author, --markup, and --focus, with no way
to name a parent. hunk session comment apply accepts the same fields per
entry in its stdin batch. The closest available move is a new top-level note at
the same anchor with --author set, which sits beside the original instead of
under it.
I run hunk in a tmux split beside a coding agent. The agent opens the review, I
annotate hunks, and the agent reads the notes back with hunk session comment list --repo . --type all --json, fixes what it can, and reloads the session.
The one thing it cannot do is answer a note — say which of two readings it
took, or why it left something alone. The agent also can't easily point out
where it addressed the comment or whether it agrees or has a nuance I may not
have considered. Those answers end up in the terminal conversation instead of
beside the code they concern, which is where they are useful. This also offers an easy way to see whether a comment is 'done'.
Related issues. #115 asks for user notes to reach a connected agent as prompts,
with the agent's response arriving back in the same thread, and its acceptance
criteria need a transport to do it. This is only the write half of the CLI
surface, built on threading that has already shipped — #115 was filed in March,
before replyTo landed and before #848 closed. #380 covers editing an existing
comment from the CLI, which is the same class of TUI/CLI parity gap with a
different verb.
How? (optional)
The model looks to be in place already. SessionReviewNoteSummary carries
parentId, the TUI threads through hunk.review.replyToActiveNote, and
replies nest without a depth limit, so this is mostly exposing existing
structure on comment add and in the comment apply schema.
Checked on hunk 0.20.0 installed with Homebrew, on macOS 26.5.2 with zsh,
Ghostty and tmux.
Happy to implement it if the approach looks right.
What do you want to change?
Add a way to reply to an existing inline review note from the session CLI.
hunk session comment add --reply-to <note-id>creates a reply to that note,inheriting its anchor the way the TUI's
Rdoes.comment applybatch payload.hunk session comment list --jsonreports the parent so a caller canreconstruct a thread.
SessionReviewNoteSummaryalready carriesparentId,so this may work already.
--reply-tobehaves exactly as it does today.Non-goals:
answer into the session. That's Support replying to inline agent comments and route replies back to the agent #115 and it depends on transport work.
Why?
The TUI can reply to a review note, but this isn't exposed through the CLI, so
agents can't easily drive replies to comments.
In the TUI,
R(hunk.review.replyToActiveNote) replies to the active note,replies inherit the parent's code anchor, and they nest. From the CLI,
hunk session comment addtakes--file,--old-line/--new-line,--summary,--rationale,--author,--markup, and--focus, with no wayto name a parent.
hunk session comment applyaccepts the same fields perentry in its stdin batch. The closest available move is a new top-level note at
the same anchor with
--authorset, which sits beside the original instead ofunder it.
I run hunk in a tmux split beside a coding agent. The agent opens the review, I
annotate hunks, and the agent reads the notes back with
hunk session comment list --repo . --type all --json, fixes what it can, and reloads the session.The one thing it cannot do is answer a note — say which of two readings it
took, or why it left something alone. The agent also can't easily point out
where it addressed the comment or whether it agrees or has a nuance I may not
have considered. Those answers end up in the terminal conversation instead of
beside the code they concern, which is where they are useful. This also offers an easy way to see whether a comment is 'done'.
Related issues. #115 asks for user notes to reach a connected agent as prompts,
with the agent's response arriving back in the same thread, and its acceptance
criteria need a transport to do it. This is only the write half of the CLI
surface, built on threading that has already shipped — #115 was filed in March,
before
replyTolanded and before #848 closed. #380 covers editing an existingcomment from the CLI, which is the same class of TUI/CLI parity gap with a
different verb.
How? (optional)
The model looks to be in place already.
SessionReviewNoteSummarycarriesparentId, the TUI threads throughhunk.review.replyToActiveNote, andreplies nest without a depth limit, so this is mostly exposing existing
structure on
comment addand in thecomment applyschema.Checked on hunk 0.20.0 installed with Homebrew, on macOS 26.5.2 with zsh,
Ghostty and tmux.
Happy to implement it if the approach looks right.