Reopen a Closed Pull Request with gh pr reopen

You will reopen a closed GitHub pull request from a Linux terminal, optionally leave a reopening comment, and verify the pull request state afterwards. Allow about five minutes for a pull request you can identify and a working gh login. This changes remote GitHub state, so use a pull request number or URL you have checked before pressing Enter.

1. Check the installed command and your login

This guide follows the gh-pr-reopen(1) manual installed with the gh package. On this machine the package reports version 2.45.0-1ubuntu0.3+esm3, while the executable reports GitHub CLI version 2.87.3. The executable's help and the local manual agree on the command shape. Your distribution may package a different release, so check the local help when a script depends on a detail.

$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh pr reopen --help
Reopen a pull request

USAGE
  gh pr reopen {<number> | <url> | <branch>} [flags]

Authentication is a prerequisite for the remote operation. Check it without changing a pull request:

$ gh auth status

The command should identify an active account and host. If it reports that you are not logged in, stop here and authenticate through your normal GitHub CLI process. Do not paste an access token into a shell command or into a comment.

2. Identify the repository explicitly

gh can infer a repository from the current Git checkout, but that is an easy source of mistakes when several terminals or clones are open. In a checkout, inspect the remote before choosing a pull request:

$ git remote -v
origin  https://github.com/OWNER/REPOSITORY.git (fetch)
origin  https://github.com/OWNER/REPOSITORY.git (push)

Replace OWNER/REPOSITORY below with the repository you have confirmed. The inherited -R or --repo option accepts the [HOST/]OWNER/REPO form. It is an ordinary CLI option, not a shell variable, and it does not require root.

Checkpoint: if you are not in the intended checkout, use an explicit repository on both the inspection and reopening commands:

$ gh pr view 123 --repo OWNER/REPOSITORY --json number,title,state,url
{
  "number": 123,
  "state": "CLOSED",
  "title": "Example change",
  "url": "https://github.com/OWNER/REPOSITORY/pull/123"
}

The field names above are supported by the installed gh pr view help. The title, number and URL in your output must describe the pull request you intend to change. If you use a URL as the target, check its owner and repository just as carefully.

3. Reopen the pull request

Reopening is a state-changing operation performed against GitHub. It does not need sudo, but your GitHub account must have enough permission to update the pull request. Use a number, URL or branch name after gh pr reopen:

$ gh pr reopen 123 --repo OWNER/REPOSITORY

The command may not print a useful success summary. Treat its exit status as the first check, then query GitHub for the state. A non-zero exit status means the requested change was not confirmed; read the error before retrying rather than repeatedly sending the command.

You can target the same pull request by URL:

$ gh pr reopen https://github.com/OWNER/REPOSITORY/pull/123

Do not combine an untrusted URL or branch name with shell syntax. Quote a URL if it has been copied from another command or contains characters that your shell could interpret.

4. Add a reopening comment when the context matters

The -c and --comment flags add a comment as part of the reopening request. Keep the message factual and avoid putting secrets, private incident details or unreviewed shell output into a public repository conversation:

$ gh pr reopen 123 --repo OWNER/REPOSITORY \
    --comment 'Reopened to address the review feedback in the latest branch update.'

Use single quotes for a simple literal message so the shell does not expand punctuation. If the comment needs several paragraphs, prepare the text in a file and confirm the command's supported flags first. The local gh pr reopen interface documents only --comment; do not assume flags from another gh pr subcommand apply here.

5. Verify the new state

Query the same repository and pull request after the command returns. The state field is the compact check; the title and URL help catch a repository or number mix-up:

$ gh pr view 123 --repo OWNER/REPOSITORY --json number,title,state,url
{
  "number": 123,
  "state": "OPEN",
  "title": "Example change",
  "url": "https://github.com/OWNER/REPOSITORY/pull/123"
}

If the state remains CLOSED, inspect the error from the reopen command and check your permissions, authentication host and target repository. If the pull request was merged, GitHub may not permit reopening it; do not try to work around that by editing the repository through another API without understanding the consequences.

There is no local undo command. To close the pull request again, use the GitHub web interface or a separately verified command that your installed CLI documents for closing pull requests. Confirm that this is the intended reversal before taking it, because closing can affect review and automation workflows.

Common traps

• Wrong repository: an omitted --repo can make the current checkout decide the target. Use the explicit form when the operation matters.
• Wrong identifier: a branch name can resolve to a different pull request than the one you had in mind. A checked URL or number is easier to audit.
• Missing permission: a valid login does not guarantee permission to change a pull request in an organisation or on another host.
• Confusing comments with state: --comment adds conversation text; it is not a dry-run note and does not preview the operation.
• Assuming local Git changes are involved: reopening changes the pull request on GitHub. It does not checkout a branch, modify files or alter your working tree.