Skip to content

gh pr/issue comment allow editing selected comments #10865

Open
Open
gh pr/issue comment allow editing selected comments#10865
Labels
discussFeature changes that require discussion primarily among the GitHub CLI teamgh-issuerelating to the gh issue commandgh-prrelating to the gh pr commandneeds-designAn engineering task needs design to proceedneeds-investigationCLI team needs to investigateneeds-productAn issue that requires prioritization considerations

Description

@shanduur
shanduur
opened on Apr 24, 2025

Overview

Introduce a new flag, --edit-selector, for both issue comment and pr comment commands. When paired with --edit-last, this flag lets users supply a jq‐style filter expression to select exactly which comment to edit. Without it, the CLI continues to edit only the most recent comment authored by the current user.

Motivation

  • Existing limitation: “edit last” always grabs the latest user comment; in busy threads or CI environments, that’s brittle.
  • Deterministic scripting: allows scripts to target comments containing a known marker, ID, or other metadata, rather than relying on ordering.

Requirements

  1. New flag: --edit-selector <jq-expression>.
  2. Behavior:
    • If provided, evaluate the filter against the full set of comments.
    • If exactly one match → edit that comment.
    • If zero matches → error “no comments found for selector.”
    • If multiple matches → choose the last match in chronological order (mirroring the existing “last” semantics).
  3. Fallback: without --edit-selector, preserve current behavior of editing only the very last comment.

CLI Interface

# Edit the last comment containing a custom tag:
gh pr comment --edit-last \
  --edit-selector '. | select(.body | contains("<!--build-status-->"))'

# Edit by explicit comment ID:
gh issue comment --edit-last \
  --edit-selector '. | select(.id == "2823981412")'
  • Supplying --edit-selector without --edit-last should produce a usage error.
  • Common selectors might include:
    • . | select(.body | contains("TODO"))
    • . | select(.id == "2823981412")

High-Level Workflow

flowchart TD
  A[User] --> B[Parse CLI flags into Options including EditSelector string]
  B --> C[Fetch list_of_comments from API]
  C --> D{Is EditSelector provided?}
  D -- No --> E[Select last comment in list_of_comments]
  D -- Yes --> F[Invoke selectComment selector, list_of_comments]
  F --> G{Any matches?}
  G -- No --> H[Error: no comments found for selector]
  G -- Yes --> I[Pick the last matching comment]
  E --> J[Call UpdateComment API with selected comment ID and new body]
  I --> J[Call UpdateComment API with selected comment ID and new body]
Loading

Testing Strategy

Design table of test cases:

Scenario Selector Comments Expected Outcome
No comments any expression [] Error “no comments for selector”
Single match select by unique body substring [A(unique), B, C] Edit A
Multiple matches select by common tag [A(tag), B(tag), C(tag)] Edit C (last match)
Invalid selector syntax malformed jq [any list] Error “parsing selector”
  • Automated unit tests should cover all scenarios above.
  • Integration tests should verify end-to-end CLI behavior.

Future Considerations

  • Strict vs. lenient multiple-match handling: offer a flag to error on multiple matches instead of auto-selecting the last.
  • Selector shortcuts: allow specifying only an ID (e.g. --edit-selector-id 12345) for convenience.
  • Performance: cache parsed selectors when used repeatedly in loops.

#10850

Activity

  1. cliAutomation
    added
    needs-triageneeds to be reviewed
    on Apr 24, 2025

  2. shanduur commented on Apr 24, 2025

    @shanduur
    shanduur
    on Apr 24, 2025
    ContributorAuthor

    cc @BagToad @williammartin

  3. jtmcg
    self-assigned this
    on Apr 24, 2025
  4. jtmcg
    added
    discussFeature changes that require discussion primarily among the GitHub CLI team
    on Apr 25, 2025
  5. BagToad
    assigned
    BagToad
    and unassigned
    jtmcg
    on May 10, 2025

  6. BagToad commented on May 10, 2025

    @BagToad
    BagToad
    on May 10, 2025
    Member

    👋 Hey @shanduur ✨ sorry for the delay on this one.

    Editing comments is one of the features that we know has some gaps, and I think the approach you have proposed is reasonable ❤

    However, there are some concerns we have to iron out when we have time before we can accept work on a feature like this:

    • Introduction of a new jq based pattern for selecting comments. When we introduce new patterns like this to the CLI, it sets precedent for other commands to follow suite. We want to be careful that when we do this, we are implementing the right solution. Changing course after the fact when it comes to command line flags is dangerous, as we endeavor to not break scripts where someone might be using the flag.
    • The user friendliness of this leaves a bit to be desired. It's natural for someone with jq knowledge to be comfortable with an interface like this, but we think there might be an opportunity for a design here that is more approachable to everyone. We don't know what that design would be, so we're hoping to hear feedback and investigate further.

    Personally, I've never been a terribly large fan of --edit-last anyways and I think it would be better to have a complete experience that allows editing any comment.

    With all this in mind, I'm going to label this as needing more investigation and more eyes from our product folks for now.

    Thanks again for trying to improve gh! 🍻

  7. BagToad
    added
    needs-designAn engineering task needs design to proceed
    needs-investigationCLI team needs to investigate
    needs-productAn issue that requires prioritization considerations
    gh-prrelating to the gh pr command
    gh-issuerelating to the gh issue command
    and removed
    needs-triageneeds to be reviewed
    on May 10, 2025
  8. BagToad
    removed their assignment
    on May 10, 2025

  9. A4-Tacks commented on Feb 19, 2026

    @A4-Tacks
    A4-Tacks
    on Feb 19, 2026
    Contributor

    Personally, I've never been a terribly large fan of --edit-last anyways and I think it would be better to have a complete experience that allows editing any comment.

    I created a similar bash script https://github.com/A4-Tacks/my-bash-utils/blob/main/github-comment-review

    Example github-comment-review -u https://github.com/A4-Tacks/my-bash-utils/pull/2#issuecomment-3924422154

    If gh-cli is implemented in this way, it will be simple and practical, like:

    gh issue comment --edit-last https://github.com/A4-Tacks/my-bash-utils/pull/2#issuecomment-3924422154

    But the current behavior of the above command is equivalent to
    gh issue comment --edit-last A4-Tacks/my-bash-utils/pull/2,
    which is a true 'edit-last'

    Meanwhile, this implementation is also compatible with edit-selector, requiring only like:

    url=$(gh issue view --json comments | jq 'first(.[][] | select(.body == ...)).url')
gh issue comment --edit-last "$url"

  10. maxbeizer commented on Mar 15, 2026

    @maxbeizer
    maxbeizer
    on Mar 15, 2026
    Contributor

    Personally, I've never been a terribly large fan of --edit-last anyways and I think it would be better to have a complete experience that allows editing any comment.

    +1 to this. Here's a sketch of what an alternative design could look like, splitting the interactive and scripting use cases:

    Interactive (human-friendly):

    # Opens a picker showing comment previews, then edits the selected one
gh pr comment 123 --edit
gh issue comment 456 --edit

    This would present something like an fzf-style (or bubbletea) list of comments (author, timestamp, body preview), let you pick one, and open your editor. No jq knowledge needed, consistent with the interactive patterns gh already uses elsewhere (e.g., gh pr create prompting for reviewers).

    Scripting (deterministic):

    # Edit a specific comment by  no ambiguity, no filtering DSLID 
gh pr comment 123 --edit-id IC_abc123
gh issue comment 456 --edit-id 2869076399

    Comment IDs are already available via --json comments or the API, so this composes naturally with existing gh + jq workflows without baking a jq selector into the flag itself:

    # Find and edit a comment by content (using existing jq, not a new flag)
id=$(gh pr view 123 --json comments --jq '.comments[] | select(.body | contains("<!-- status -->")) | .id')
gh pr comment 123 --edit-id "$id"

    URL-based (zero lookup needed):

    # Paste a comment permalink  gh extracts the comment ID from the URLdirectly 
gh issue comment --edit https://github.com/cli/cli/issues/10865#issuecomment-2869076399

    People already copy comment URLs from the browser, so this would be the lowest-friction path. Similar to how @A4-Tacks suggested above.

    This avoids introducing a new filtering pattern into gh's flag surface while covering the "quick edit in a terminal", "deterministic CI script", and "I'm looking right at the comment" use cases. --edit-last could stick around as sugar for the common case.

    Happy to take a crack at it @BagToad if you think that's a good way forward 🙇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussFeature changes that require discussion primarily among the GitHub CLI teamgh-issuerelating to the gh issue commandgh-prrelating to the gh pr commandneeds-designAn engineering task needs design to proceedneeds-investigationCLI team needs to investigateneeds-productAn issue that requires prioritization considerations

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions