Home / Alt manpages / gh-issue-reopen(1)

  • gh-issue-reopen(1)
  • User command
  • linux

Reopen a GitHub Issue Safely with gh issue reopen

Closed as stale last month, and now the same bug is back in production: gh issue reopen puts it back open, with an optional comment explaining why.

The command changes remote repository state, so allow about five minutes for a straightforward case and pause to confirm the repository and issue number before running it.

Prerequisites

  • You need: GitHub CLI installed and authenticated as an account that can edit issues in the target repository.
  • Version: this guide is based on GitHub CLI 2.87.3, installed as the gh package on the reference system. The local manual exposes only one command-specific option, --comment; repository selection is inherited from the parent issue command.

Run these checks first:

gh --version
gh issue reopen --help

The help output should show gh issue reopen {<number> | <url>}, the -c, --comment option, and the -R, --repo option. If the version or help output differs, use the output on your machine as the authority for available flags.

Checkpoint

You have identified the exact issue and confirmed that your account can work on its repository.

1. Identify the repository and issue

The issue argument can be an issue number or a full issue URL. A number is convenient when your current directory is a local checkout of the intended repository:

gh issue view 123 --json title,state,url

Replace 123 with the closed issue number. Review the returned title, URL and state. Do not rely on the number alone if you have several repositories in nearby directories.

If you are not in the correct checkout, select the repository explicitly with -R:

gh issue view 123 -R OWNER/REPOSITORY --json title,state,url

For a GitHub Enterprise host, the inherited option accepts the [HOST/]OWNER/REPO form. You can also avoid repository context by passing the issue URL:

gh issue view https://github.com/OWNER/REPOSITORY/issues/123 --json title,state,url

These are read-only checks. If the issue is already open, stop here: reopening it would not correct the underlying workflow and may create an unnecessary audit event.

2. Reopen the issue

After checking the target, run the smallest command that matches your intent:

gh issue reopen 123

The command changes the issue's state on GitHub. It does not require sudo; elevated local privileges cannot grant GitHub permissions and are not relevant to this operation.

To record why the issue is being reopened, add a concise comment:

gh issue reopen 123 \
  --comment "Reopening after the regression returned in release 2.4.1."

Use -c as the shorter spelling if preferred. Put the comment in double quotes so the shell passes it as one argument. Check the wording before pressing Enter: a comment is a durable remote record and is visible to people with access to the issue.

For another repository, combine the issue number and repository selector:

gh issue reopen 123 -R OWNER/REPOSITORY \
  --comment "Reopening for the next maintenance cycle."

You can use the URL form instead:

gh issue reopen https://github.com/OWNER/REPOSITORY/issues/123

A successful state change normally produces no useful report in the terminal. Treat a non-zero exit status or an error message as a failed operation, not as evidence that the issue changed.

Checkpoint

The command completed without an error. Do not run it repeatedly just because the terminal was quiet.

3. Verify the remote state

Ask GitHub CLI for the issue state rather than inferring success from the command returning to your shell:

gh issue view 123 -R OWNER/REPOSITORY --json title,state,url \
  --jq '.state'

Expected output is:

OPEN

Run the check without -R when the current checkout is already the intended repository. Include the title and URL in a human review if you are working from a queue:

gh issue view 123 -R OWNER/REPOSITORY --json title,state,url

If the result is still CLOSED, inspect the error from the reopen command, confirm the repository host and permissions, and check the issue again. A stale local assumption about the current repository is a common distraction.

Failure handling and recovery

  • Missing argument, malformed URL or wrong repository. gh issue reopen accepts only an issue number or URL, so fix the input before retrying.
  • Not authorised. Authenticate the intended account and verify its access through your normal GitHub CLI process.
  • Security warning: do not paste access tokens into a comment, shell history or issue URL.

If you reopened the wrong issue, or the issue no longer needs work, the reverse operation is a separate state-changing command:

gh issue close 123 -R OWNER/REPOSITORY \
  --comment "Closing again because this was reopened in error."

Confirm the target with gh issue view before closing it. Closing is not an undo for the comment: any reopening comment remains in the issue history. If the issue was closed as a duplicate or for another specific reason, review that context manually before changing its state again.

Done means

  • The issue title, URL and repository were checked before the state change.
  • gh issue reopen completed without an error.
  • The optional comment says why the issue is being reopened and contains no secrets.
  • gh issue view ... --json state --jq '.state' reports OPEN.
  • Any mistaken reopen has been reviewed before using the separate close command.