Home / Alt manpages / gh-issue-unpin(1)

  • gh-issue-unpin(1)
  • User command
  • linux

Unpin a GitHub Issue with gh issue unpin

That pinned issue was useful in March and is embarrassing now, so gh issue unpin takes it off the repository's front page from your terminal. It takes about five minutes on GitHub CLI 2.87.3 (the version installed on this machine) and accepts an issue number or a full issue URL.

  • You need: the gh command, an authenticated session, access to the repository, and an issue that is currently pinned.
  • What it changes: repository metadata on GitHub. The issue body, comments, labels and code are untouched.
  • Privileges: no sudo.

1. Check the installed command

Start read-only, so the syntax you use matches the installed binary:

$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh issue unpin --help

The shape is gh issue unpin {<number> | <url>} [flags]. The only repository-selection option is the inherited -R or --repo flag. The help text should show the same number-or-URL form before you go on.

Checkpoint

If gh issue unpin --help fails, stop. Fix the local CLI installation or your PATH instead of trying a similar-looking command from memory.

2. Confirm the repository and issue state

Do not unpin by number until you know which repository gh will use. From a checked-out repository, inspect its remote:

$ git remote get-url origin
https://github.com/OWNER/REPOSITORY.git

Replace OWNER, REPOSITORY and ISSUE_NUMBER below with real values. This read-only query confirms the issue identity and its current pin state:

$ gh issue view ISSUE_NUMBER --repo OWNER/REPOSITORY --json number,title,isPinned,url
{
  "isPinned": true,
  "number": ISSUE_NUMBER,
  "title": "Your issue title",
  "url": "https://github.com/OWNER/REPOSITORY/issues/ISSUE_NUMBER"
}

Your title and URL will differ. Two stop signs:

  • Already unpinned. If isPinned is false, there is nothing to remove.
  • Wrong issue. If the number points at a different issue than expected, correct the repository or number before changing anything.

Tip

A repository-relative number is only safe when the repository context is unambiguous. An issue URL is often clearer when you work across several repositories or hosts.

3. Unpin by issue number

With repository and state confirmed, run the change explicitly against that repository:

$ gh issue unpin ISSUE_NUMBER --repo OWNER/REPOSITORY
$ printf 'exit status: %s\n' "$?"
exit status: 0

The manpage promises no output, so judge by exit status, not by a success sentence. Status 0 means the CLI completed the request. Non-zero means it did not, so do not assume the issue changed.

There is no elevated-privilege version of this command. GitHub checks authorisation and repository permissions, not sudo. Never put a token on the command line or paste one into shell history.

4. Verify the change

Query the same issue again, with the same explicit repository:

$ gh issue view ISSUE_NUMBER --repo OWNER/REPOSITORY --json number,title,isPinned,url
{
  "isPinned": false,
  "number": ISSUE_NUMBER,
  "title": "Your issue title",
  "url": "https://github.com/OWNER/REPOSITORY/issues/ISSUE_NUMBER"
}

The field that matters is isPinned. The issue still exists, and nothing was closed or removed from the discussion. If it still says true, check you used the same owner, repository and number, then look at the command's error output and your authentication state.

Checkpoint

Stop when the returned URL and number match your intended issue and isPinned is false. Keep this output in the change record if the unpin was part of a release or moderation task.

5. Use a URL when context is easy to lose

The URL form removes any doubt about repository and issue:

$ gh issue unpin https://github.com/OWNER/REPOSITORY/issues/ISSUE_NUMBER

Copy the full URL from the issue page and read it before pressing Enter. A URL for another repository is still a valid target, so it does not replace checking the owner and repository. On GitHub Enterprise, use that host's issue URL; the local syntax also allows a host-qualified repository with --repo.

6. Recover from a mistake

Unpinning is reversible, but the undo is another repository change. If you removed the wrong pin, confirm the issue URL first, then restore it with the matching pin command:

$ gh issue pin ISSUE_NUMBER --repo OWNER/REPOSITORY
$ gh issue view ISSUE_NUMBER --repo OWNER/REPOSITORY --json number,isPinned,url
{
  "isPinned": true,
  "number": ISSUE_NUMBER,
  "url": "https://github.com/OWNER/REPOSITORY/issues/ISSUE_NUMBER"
}

Warning

Do not run the recovery command as a blind retry. First establish whether the original unpin succeeded, because repeating a state-changing command makes the audit trail harder to read, especially when several people maintain the repository.

Common traps

  • Wrong repository: a number such as 23 means something only inside its repository. Add --repo OWNER/REPOSITORY or use the complete URL.
  • Already unpinned: check isPinned first. There is no useful second removal to perform.
  • Not authenticated: run the read-only checks first and fix the GitHub CLI login through your normal account process. Do not expose credentials in shell arguments.
  • Insufficient permission: a valid issue URL does not grant permission to change pins. If GitHub rejects the request, ask a repository administrator or maintainer.
  • Unclear result: keep the error, then repeat the read-only gh issue view query. Treat the reported state as authoritative before attempting an undo.

Done means

  • Syntax checked: the installed gh issue unpin help matched what you ran.
  • Target confirmed: owner, repository, issue number and issue URL all matched.
  • Command clean: the unpin returned exit status 0.
  • State verified: a second issue query reported isPinned: false.
  • Nothing else moved: no issue content, comments, labels or source files were changed.