Comment on a Pull Request with gh pr comment

gh pr comment adds, edits or removes a comment on a GitHub pull request straight from the shell. This guide covers multi-line text from a file or standard input, and how to edit or delete your own latest comment without confusing a local branch with the pull request you meant to change. The examples match GitHub CLI 2.87.3, installed here from package gh.

Allow about ten minutes. You need GitHub CLI, an authenticated account with permission to comment on the repository, and the pull request number, URL or branch name. These commands change remote review data, so read the target carefully before pressing Enter, especially for editing and deletion. No command in this guide needs sudo.

1. Check the installed command

Start with read-only version and help checks, to confirm which syntax is available before you send anything to GitHub:

$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh pr comment --help

The command accepts a pull request number, URL or branch after gh pr comment. Omit the comment body and it prompts interactively; for repeatable work, pass the body explicitly or read it from a file.

Checkpoint: make sure the repository and pull request are the ones you intend to change. If you are not in the right local checkout, use the inherited --repo option in the form HOST/OWNER/REPO or OWNER/REPO.

2. Add a short comment by pull request number

Use --body for a short message. The pull request number is an explicit target, easier to review in a script than relying on the current branch:

$ gh pr comment 123 --body "The test fix is ready for another review."

On success, GitHub CLI normally prints a link to the new comment and returns exit status 0. If it errors, inspect that error and its status rather than repeating the command blindly: a retry can create a duplicate comment if the first request reached GitHub but the response got interrupted.

To target a repository other than the current checkout, make it explicit:

$ gh pr comment 123 --repo example/project --body "Testing the release candidate."

Replace both placeholders, and do not put an untrusted value directly into a shell command. Quote message text so spaces, punctuation and shell characters stay part of the comment.

3. Send a multi-line comment from a file

For a review note with several paragraphs, write the text in a temporary or already reviewed file and pass it with --body-file:

$ gh pr comment 123 --body-file review-note.txt

The file contents become the comment body. This keeps shell quoting out of the operation and gives you a place to proofread links, commands and sensitive information before submission. Check the file as the same user who will run the command:

$ test -r review-note.txt && wc -l -c review-note.txt
      6     248 review-note.txt

The exact counts will differ. If the file is not readable, fix its path or permissions before calling GitHub CLI: do not reach for sudo to read a review file unless your system administrator has deliberately placed it outside your account's access.

You can also read the body from standard input, useful when another command produced the text (inspect that output first if it might include generated or untrusted data):

$ gh pr comment 123 --body-file - < review-note.txt

Here - means standard input, not a file literally named -. The redirection happens in your shell before gh even starts.

4. Use the editor or browser for a deliberate draft

Both skip the normal body prompt, but they still submit a comment to the selected pull request. If the editor or browser action gets cancelled, treat that as a cancelled operation and check the pull request in GitHub before trying again.

5. Edit your latest comment

To change the latest comment authored by your current GitHub user on a pull request, combine --edit-last with a new body:

$ gh pr comment 123 --edit-last --body "Updated: the failing test now passes."

This does not edit an arbitrary comment, and it will not pick up the latest comment from another author. If no comment from you exists, the operation fails unless you add --create-if-none:

$ gh pr comment 123 --edit-last --create-if-none --body "Initial status update."

Use that combination only when creating a new comment is an acceptable fallback. Otherwise leave --create-if-none out, so a missing comment stops the workflow rather than creating unexpected review history.

6. Delete your latest comment only after checking the target

Warning: Deletion changes remote review history and should be treated as irreversible for this workflow. The command removes the latest comment by your current user on the selected pull request:

$ gh pr comment 123 --delete-last

Without --yes, GitHub CLI asks for confirmation: keep that prompt while working interactively. The non-interactive form skips it and suits only a target and deletion already checked:

$ gh pr comment 123 --delete-last --yes

There is no matching restore option in gh pr comment. Copy any text that must be retained into a reviewed file before deletion. If you deleted the wrong comment, use the GitHub web interface or your organisation's recovery process to report it; do not assume a second CLI command can undo it.

7. Diagnose failures without creating duplicates

The command documents four general exit classes: 0 for success, 1 for an error, 2 for cancellation and 4 when authentication is required. A status of 4 means you need to authenticate GitHub CLI, but that itself sits outside this guide's state-changing examples: check the target, credentials and repository access first.

If a command appears to hang, remember an omitted body starts an interactive prompt. Pressing Enter is not a safe way to test whether the operation was skipped: cancel deliberately, then rerun with --body or --body-file after checking the target. If you hit an authentication or permission error, do not solve it with sudo: root privileges do not grant GitHub permissions, and they make your CLI configuration harder to reason about. If a request may have succeeded despite a lost connection, inspect the pull request's conversation before retrying.

Done means