Post a Verified GitHub Issue Comment with gh

There is no undo for a comment posted to the wrong issue with gh issue comment, so this guide checks the target before it checks the wording. The examples use GitHub CLI 2.87.3, installed here as package gh. The local gh-issue-comment(1) manual is dated March 2026; the installed command's help also lists newer comment-management flags, so check your own help before copying an unfamiliar option.

Allow about ten minutes for a first run. You need GitHub CLI, an authenticated account with permission to comment on the issue, and the repository name if you are not working inside a checkout. Posting a comment changes remote issue history.

1. Check the installed command

Start with read-only checks. These need no sudo and do not contact GitHub:

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

Look for the shape gh issue comment {<number> | <url>} [flags]. The number resolves in the current repository context; a full issue URL is less ambiguous, especially when your shell is not inside the intended checkout.

2. Confirm the repository and issue

From a checkout of the correct repository, inspect the issue before writing anything:

$ gh issue view 123 --comments
Issue title
opened by OWNER. 2 comments. (label)

  Issue body and existing comments appear here

View this issue on GitHub: https://github.com/OWNER/REPO/issues/123

Replace 123 with the real issue number. Outside a checkout, supply the repository explicitly to both commands:

$ gh issue view https://github.com/OWNER/REPO/issues/123 --comments
$ gh issue comment https://github.com/OWNER/REPO/issues/123 --body 'Test update from the terminal'

That second command posts a real comment, so do not run it until the text and URL are both right. Or keep the issue number from the first command and add --repo OWNER/REPO to the eventual comment command instead.

3. Post a short message with --body

A message that fits comfortably on one line can go straight in as one quoted shell argument:

$ gh issue comment 123 --repo OWNER/REPO \
    --body 'The fix is ready for review. I have added a regression test.'
https://github.com/OWNER/REPO/issues/123#issuecomment-... 

The URL printed after a successful request is the confirmation that matters; its comment identifier varies, so do not script against the literal example above. Command returns an error: treat the operation as uncertain until you check the issue in the browser or with gh issue view 123 --comments, since a network failure does not always tell you whether the server received the request.

Quote the body with single quotes when it holds spaces or characters such as $, backticks or !. A single quote inside the message itself: use a file rather than fighting shell quoting.

4. Use a file for multiline or reviewed text

A body file is easier to review and sidesteps accidental shell expansion. Write or inspect it with your usual editor, then send it with --body-file:

$ editor /tmp/issue-123-comment.txt
$ sed -n '1,120p' /tmp/issue-123-comment.txt
$ gh issue comment 123 --repo OWNER/REPO \
    --body-file /tmp/issue-123-comment.txt
https://github.com/OWNER/REPO/issues/123#issuecomment-...

You can also read the body from standard input with --body-file -, useful when another trusted command produces the text:

$ printf '%s\n' 'Build completed successfully.' | \
    gh issue comment 123 --repo OWNER/REPO --body-file -

Review pipelines before wiring them up this way. A command that includes logs or user-controlled text can publish more than you intended.

5. Choose interactive editing when the wording needs attention

With no body flag, gh issue comment prompts interactively for the text. --editor skips the prompt and opens your configured text editor instead, for a normal edit-and-review cycle:

$ gh issue comment 123 --repo OWNER/REPO --editor

--web opens the browser to write the comment there. Both are ordinary user actions needing no elevated privileges. Editor or browser fails to open: fall back to --body-file or --body after checking the target again.

6. Diagnose the common failures

• "Not logged in." Authentication needs repairing before posting. Check with gh auth status. Never paste a token into a comment, shell history or an issue body; run gh auth login only when ready to follow its interactive flow, using the account meant for this repository.
• Repository resolution error. Usually the current directory is not the repository you thought, or OWNER/REPO is misspelled. Prefer a full issue URL or an explicit --repo, then run gh issue view again.
• Permission or visibility error. Not fixed by sudo: GitHub authorisation is separate from Linux privileges.

Accidentally published the wrong text: check gh issue comment --help for --edit-last or --delete-last if your installed release supports them. The latter is destructive and may prompt for confirmation; verify the last comment is yours before using it. Those flags unavailable: edit or delete the comment in GitHub's web interface after confirming the comment's identity. There is no safe local rollback that can guarantee removing a remote comment.