Post a Verified GitHub Issue Comment with gh

You will finish with a repeatable way to add one comment to a GitHub issue from a Linux terminal, verify that the request reached the intended repository, and avoid leaking shell syntax into the message. 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. Read the target and message before running the write command; there is no general undo for an accidentally published comment.

1. Check the installed command

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

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

Look for the command shape gh issue comment {<number> | <url>} [flags]. The number is resolved 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:

$ 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. If you are 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 use it until the text and URL are correct. Alternatively, keep the first command's issue number and add --repo OWNER/REPO to the eventual comment command.

3. Post a short message with --body

For a message that fits comfortably on one line, pass it 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 useful confirmation. Its comment identifier is variable, so do not write scripts that expect the literal example above. If your command returns an error, treat the operation as uncertain until you check the issue in the browser or with gh issue view 123 --comments; a network failure does not always tell you whether the server received the request.

Quote the body with single quotes when it contains spaces or characters such as $, backticks or !. If the message itself contains a single quote, use a file instead of trying to make complicated shell quoting.

4. Use a file for multiline or reviewed text

A body file is easier to review and avoids accidental shell expansion. Create or inspect the file 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-...

The filename is only an example. Do not put access tokens, private incident data or credentials in a comment file. Remove sensitive temporary material after checking the comment, and remember that deleting the local file cannot retract a comment already sent to GitHub.

You can also read the body from standard input with --body-file -. This is 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 using them. A command that includes logs or user-controlled text can publish more than intended.

5. Choose interactive editing when the wording needs attention

Without a body flag, gh issue comment interactively prompts for the comment text. The --editor option skips the prompt and opens your configured text editor. Use this when you want a normal edit-and-review cycle:

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

--web opens the browser to write the comment instead. These are ordinary user actions and do not require elevated privileges. If an editor or browser fails to open, use --body-file or --body after checking the target again.

6. Diagnose the common failures

A message such as "not logged in" means authentication must be repaired before posting. Check the account with gh auth status. Do not paste a token into a comment, shell history or an issue body. Run gh auth login only when you are ready to follow its interactive authentication flow, and use the account intended for this repository.

A repository resolution error usually means the current directory is not the repository you thought it was, or that OWNER/REPO is misspelled. Prefer a full issue URL or an explicit --repo, then run gh issue view again. A permission or visibility error is not fixed by sudo; GitHub authorisation is separate from Linux privileges.

If you accidentally publish the wrong text and the installed help supports it, inspect gh issue comment --help for --edit-last or --delete-last. The latter is destructive and may prompt for confirmation; verify that the last comment is yours before using it. If those flags are unavailable, edit or delete the comment in GitHub's web interface after confirming the comment identity. There is no safe local rollback that can guarantee removal of a remote comment.