Reopen a Locked GitHub Issue with gh issue unlock

A locked issue stops every new comment stone dead, and gh issue unlock is the one command that lifts it again. The installed version here is GitHub CLI 2.45.0, from Ubuntu package gh 2.45.0-1ubuntu0.3+esm3.

Allow about five minutes. You need the gh package, an authenticated CLI session, and permission to change the target issue. It needs no sudo, but it does need a deliberate final check: once the lock is off, anyone with the relevant access can comment again.

1. Check the command and your account

Read the installed help before touching anything. This is read-only and does not contact the issue:

$ gh issue unlock --help
Unlock issue conversation

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

INHERITED FLAGS
      --help                     Show help for command
  -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format

The local manual lists no command-specific flags. Identify the issue by number or by full URL: use the URL form across several hosts or repositories, and use --repo when a bare number would be ambiguous.

Check the active account before changing anything:

$ gh auth status

The output names the GitHub host and account the CLI will use. Wrong account? Stop. Do not assume the command will offer to switch identities for you.

2. Pin down the exact issue

Write down the repository and issue number from the issue page itself. Say the target is issue 184 in octo-org/sample-project. A bare number relies on the current repository context, so make that context explicit:

$ gh issue unlock 184 --repo octo-org/sample-project

Or pass the full URL, handy when the repository is not your current checkout:

$ gh issue unlock 'https://github.com/octo-org/sample-project/issues/184'

Keep the URL quoted. This example has no shell metacharacters in it, but quoting protects you against accidental edits and future query strings.

3. Treat it as one-way

Removing the lock changes the issue's conversation state on GitHub. It does not delete comments, reopen the issue, change labels or touch repository settings; it only clears the block on further conversation.

Before running the command, read the target once more and ask whether the lock is still needed for moderation or incident handling. There is no local transaction to roll back.

$ gh issue lock 184 --repo octo-org/sample-project

Do not fire that recovery command on reflex after a failure. Establish whether GitHub actually changed the issue first; chaining state-changing commands while you are still diagnosing just adds confusion.

4. Run the command

Use the explicit repository form, and only after the checkpoint above:

$ gh issue unlock 184 --repo octo-org/sample-project

On success it normally returns to the shell with no message at all, so check the exit status as your first signal:

$ printf 'exit status: %s\n' "$?"
exit status: 0

Zero means the CLI completed the request. It does not mean you hit the repository you had in mind, so keep the --repo argument explicit in scripts and copy-pasteable runbooks.

5. Verify on GitHub, not just in the terminal

Refresh the issue page and confirm the conversation is no longer marked as locked. Check the address bar as well as the title: a good second control, since the command itself often prints nothing.

If you have a separate check that reads issue state, run it after the CLI exits cleanly and keep it separate from the command itself, so an error in the check is never mistaken for a failed unlock.

Common traps

• No usable session. gh auth status reports nothing to work with: authenticate through your normal process, then recheck. Never paste tokens into a shell history, issue comment or support ticket.
• Issue not found. Check the host, owner, repository and number. A private repository can be invisible to the active account, and a wrong repository name produces the same not-found response, so changing the issue number at random will not help.
• Found but rejected. The account may simply lack permission to change the issue's conversation state. Ask a repository administrator rather than switching accounts to route around the boundary.
• Network error mid-request. Check the issue page before retrying. The request may have reached GitHub even though the client never saw the response. Retry only once you know it is still locked.