Unlock a GitHub pull request conversation with gh pr unlock

You will remove the locked-conversation state from one GitHub pull request, verify that the command targeted the repository you intended, and know how to restore the lock if the change was accidental. Allow about five minutes for a pull request whose number or URL is already known. The examples use GitHub CLI gh 2.87.3, the version installed on this machine in February 2026.

You need an authenticated gh session with permission to change conversation state in the target repository. This is a remote, state-changing operation. It does not require sudo, and using elevated privileges on the Linux host will not grant GitHub permissions.

1. Check the installed command

Start with the local command and its exact syntax. This is a read-only check:

$ gh version
gh version 2.87.3 (2026-02-23)
https://github.com/cli/cli/releases/tag/v2.87.3
$ gh pr unlock --help
Unlock pull request conversation

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

The installed manual documents only the pull request number or URL as the command argument. The only inherited option shown there is -R/--repo, which selects a repository using [HOST/]OWNER/REPO. There is no unlock-specific reason, confirmation, dry-run or output-format option.

2. Choose an unambiguous pull request target

A pull request number is convenient when the current directory is a checkout of the correct repository:

$ gh pr unlock 123

Replace 123 with the real pull request number. If the current directory is not the repository you mean, select it explicitly:

$ gh pr unlock 123 --repo OWNER/REPOSITORY

For GitHub Enterprise Server, the repository form can include its host:

$ gh pr unlock 123 --repo HOST/OWNER/REPOSITORY

An entire pull request URL removes ambiguity when you are working across several hosts or repositories:

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

Do not paste a URL or repository name from an untrusted message without checking its host, owner and repository first. An unlock changes the conversation identified by the target, not merely a local checkout.

3. Inspect the current state before changing it

Before running the unlock command, inspect the pull request. This does not unlock anything:

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

The title and URL in your output should match the conversation you intend to change. This check confirms identity, not lock state: the documented gh pr view JSON fields do not include a conversation-lock field. Open the displayed URL in GitHub's interface if you need a visual confirmation of the current lock indicator.

4. Unlock the conversation

Unlock the verified target with the number and explicit repository:

$ gh pr unlock 123 --repo OWNER/REPOSITORY
$ printf 'gh pr unlock exit status: %s\n' "$?"
gh pr unlock exit status: 0

The local manual defines exit status 0 as successful execution. The command does not document a success message, so use the status rather than waiting for a particular line of output. A failed command returns status 1; status 2 means it was cancelled, and status 4 means authentication is required. The command may have additional operation-specific statuses, so retain the diagnostic text when investigating a failure.

Authentication and authorisation are separate checks. A logged-in account can still lack permission to unlock a conversation, or the repository can reject the operation under its access policy. Do not solve a permission error by adding sudo. Check the selected host and account with gh auth status, then have a repository administrator confirm the required permission if necessary.

5. Verify the remote change

Refresh the pull request page or reopen the URL printed by gh pr view. The lock indicator should no longer show the conversation as locked. If the page still shows a lock, check that you refreshed the correct host and repository, then rerun the read-only identity check:

$ gh pr view 123 --repo OWNER/REPOSITORY --json number,title,url
$ gh pr view 123 --repo OWNER/REPOSITORY --web

The second command opens the selected pull request in a browser. It does not itself change the conversation. A successful CLI exit status is evidence that the API operation completed; the web view is the practical check that the resulting state is visible where collaborators use it.

6. Restore the lock if the unlock was wrong

Unlocking is reversible, but restoring the lock is another remote state change. Confirm the same pull request identity first, then use the separate lock command:

$ gh pr lock 123 --repo OWNER/REPOSITORY
$ printf 'gh pr lock exit status: %s\n' "$?"
gh pr lock exit status: 0

The installed gh pr lock manual also accepts an optional reason: off_topic, resolved, spam or too_heated. Do not add a reason unless it accurately describes why the conversation is being locked:

$ gh pr lock 123 --repo OWNER/REPOSITORY --reason resolved

There is no local file to edit and no service to restart. Once the remote state is corrected, refresh the pull request page again and record the command's exit status for an audit trail.

Common traps

• Wrong repository: a number without --repo depends on the repository context that gh resolves. Use an explicit repository or full URL when in doubt.
• Wrong host: an Enterprise URL and a github.com URL are different targets. Check the host before approving a state change.
• Assuming unlock edits comments: the command changes the conversation lock state. It does not delete comments, rewrite history or change the pull request's review state.
• Parsing success text: the manual documents exit codes, not a stable success sentence. Scripts should test the status.
• Using a privileged shell: sudo gh pr unlock does not repair GitHub authentication or authorisation and can select different local configuration. Run it as the intended user.