Lock a GitHub Pull Request Conversation with gh pr lock

You will lock a pull request's conversation from the shell, attach one of GitHub CLI's supported reasons, and verify that the change reached the intended repository. The examples use GitHub CLI 2.87.3, the version installed on this machine.

Allow about five minutes. You need the gh command, an authenticated GitHub account with permission to manage the pull request, and the repository owner and name. Locking is a remote, visible change: it stops new comments on the pull request. Do not run the mutating examples against a real pull request until you have checked the repository and number.

1. Check the installed command

Read the local command help first. This is safe and does not need elevated privileges:

$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh pr lock --help
Lock pull request conversation

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

The installed manual documents one option, -r or --reason. The accepted values are off_topic, resolved, spam and too_heated. Do not substitute a free-form explanation: the option is an enumerated reason.

2. Confirm the target before changing it

Use a repository-qualified command when your current directory is not a checkout of the intended project. First inspect the pull request without changing it:

$ gh pr view 123 --repo OWNER/REPOSITORY
title:         Fix the example parser
state:         OPEN
author:        example-user
...

Replace OWNER/REPOSITORY and 123 with real values. The output varies with the pull request, so the useful checkpoint is that its title, owner and state match your intended target. A pull request URL can be used instead of a number if that is less error-prone:

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

If this lookup fails, stop. Common causes include a misspelled owner or repository, an inaccessible private repository, an expired login, and a pull request number that does not exist. Locking is not a way to test authentication.

3. Lock the conversation with a reason

After checking the target, run the change with the repository explicitly selected. This example records that the discussion is resolved:

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

A successful command normally produces no output and exits with status 0. Capture that status immediately if you need a script-friendly checkpoint:

$ status=$?
$ printf 'gh pr lock exit status: %s\n' "$status"
gh pr lock exit status: 0

The command accepts a pull request number or URL. The --repo option uses the [HOST/]OWNER/REPO form, so it can also target a GitHub Enterprise host when your account and host configuration support it.

4. Verify the lock

Read the pull request again and inspect it on GitHub if the state matters to a release or moderation process:

$ gh pr view 123 --repo OWNER/REPOSITORY --web

This opens the pull request in the configured browser. If you need a terminal-only check, use gh pr view without --web and confirm that the pull request now reports a locked conversation where the current CLI output exposes that state. The lock is separate from the pull request's open, closed, draft or merged state. It does not merge, close or delete the pull request.

5. Undo a lock when it was premature

Unlocking is a separate remote change. If you have confirmed that new conversation is appropriate, use the companion command:

$ gh pr unlock 123 --repo OWNER/REPOSITORY

Verify the result by opening the pull request again. Do not use unlock as an automatic rollback in a blind script: the decision to reopen discussion may itself need review. There is no local file to restore because the lock lives on GitHub.

Common traps

• A number without --repo is resolved using the current repository context. In a directory with a different remote, that can lock the wrong pull request. Qualify the repository when there is any doubt.
• The reason is optional, but when supplied it must be one of the four documented values. Check spelling before blaming permissions.
• A successful exit status means the CLI request succeeded. It does not mean every reader has refreshed their browser or that the pull request's underlying code changed.
• sudo is neither required nor useful. GitHub authentication and repository permissions belong to the invoking account, not to the local root account.
• Authentication errors, repository lookup errors and permission errors are different from a malformed reason. Read the error text and retry only after correcting the relevant input.