Lock a GitHub Pull Request Conversation with gh pr lock

A pull request thread that has gone off the rails stops taking new comments the moment you run gh pr lock from the terminal. The examples use GitHub CLI 2.87.3, the version installed on this machine, and the whole thing takes 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, not a comment field.

2. Confirm the target before changing it

Use a repository-qualified command when your current directory is not a checkout of the intended project. Inspect the pull request first, 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 checkpoint that matters is that its title, owner and state match your intended target. A pull request URL works 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. A misspelled owner or repository, an inaccessible private repository, an expired login, and a pull request number that does not exist are the common causes. 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. For a terminal-only check, use gh pr view without --web and confirm 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 anything.

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

Common traps

• Missing --repo. A number without it is resolved using the current repository context, which can lock the wrong pull request in a directory with a different remote. Qualify the repository when there is any doubt.
• A misspelled reason. The reason is optional, but when supplied it must be one of the four documented values. Check spelling before blaming permissions.
• Reading too much into exit status 0. It means the CLI request succeeded, not that every reader has refreshed their browser or that the pull request's underlying code changed.
• Reaching for sudo. It is neither required nor useful. GitHub authentication and repository permissions belong to the invoking account, not the local root account.
• Mixing up error types. 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.