Reopen a Closed Pull Request with gh pr reopen

Use gh pr reopen to bring a closed GitHub pull request back to life from the terminal, with or without a comment. Allow about five minutes. You need a pull request you can identify and a working gh login.

1. Check the installed command and your login

This guide follows the gh-pr-reopen(1) manual installed with the gh package. On the checked 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]

The remote operation needs authentication. Check it without changing a pull request:

$ gh auth status

The command should show an active account and host. If it says you are not logged in, stop and authenticate through your normal GitHub CLI process.

2. Identify the repository explicitly

gh can infer a repository from the current Git checkout, which is an easy way to hit the wrong one 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 need root.

$ 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 installed gh pr view help supports those field names. The title, number and URL in your output must describe the pull request you mean to change. If you target by URL, check its owner and repository just as carefully.

3. Reopen the pull request

Reopening changes state on GitHub. It does not need sudo, but your GitHub account must have 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 change was not confirmed, so read the error before retrying instead of sending the command again and again.

You can target the same pull request by URL:

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

4. Add a reopening comment when context matters

The -c and --comment flags add a comment as part of the reopening request. Keep it factual. Leave secrets, private incident details and unreviewed shell output out of 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. For a multi-paragraph comment, prepare the text in a file and confirm the supported flags first. The local gh pr reopen interface documents only --comment, so do not assume flags from another gh pr subcommand apply here.

5. Verify the new state

Query the same repository and pull request once 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 is still CLOSED, read the error from the reopen command and check your permissions, authentication host and target repository.

Common traps

• Wrong repository: an omitted --repo can let the current checkout decide the target. Use the explicit form when it 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 check out a branch, modify files or alter your working tree.