Delete the Correct GitHub GPG Key with gh

Removing the wrong GPG key from GitHub is easy to do fast and hard to undo, so gh gpg-key delete deserves a pause before the final command. This guide identifies the right key, removes it, and checks it is really gone.

Allow about ten minutes. You need GitHub CLI, an authenticated GitHub account with permission to manage its own keys, and the public key's ID as shown by GitHub. These examples use GitHub CLI 2.87.3 from the Homebrew installation at /home/linuxbrew/.linuxbrew/bin/gh. The Debian package also installed on this machine is version 2.45.0-1ubuntu0.3+esm3, but it is not the binary the shell picks.

1. Check the command before changing anything

Confirm which executable your shell will run and read its local contract. An ordinary, read-only check that needs no elevated privileges:

$ command -v gh
/home/linuxbrew/.linuxbrew/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh gpg-key delete --help
Delete a GPG key from your GitHub account

USAGE
  gh gpg-key delete <key-id> [flags]

FLAGS
  -y, --yes   Skip the confirmation prompt

The command takes one positional key ID. Its only delete-specific option is --yes, which skips confirmation. Do not use it on your first run: a shorter command is easier to paste, but the confirmation prompt is a useful last chance to catch the wrong key.

2. Confirm that gh is authenticated

Ask GitHub CLI for the current authentication status:

$ gh auth status

You need an active account on the GitHub host where the key lives. No active login: authenticate through your normal GitHub CLI process before continuing. Do not paste an access token into a command line or article. Authentication is separate from sudo; no root access is needed for this account operation.

Several GitHub accounts or hosts configured: read the status output carefully. The key has to come off the account you actually mean to change. Running the command from a particular repository does not select a repository key, because these are account-level keys.

3. List the keys and choose an exact ID

List the account's registered GPG keys:

$ gh gpg-key list

Use the displayed key ID, not a filename from your local ~/.gnupg directory and not a fingerprint copied from memory. More than one key: compare identity, key type and dates against the one you intend to remove.

Record the selected ID in a shell variable, replacing the placeholder. This does not contact GitHub or change your account:

$ KEY_ID='REPLACE-WITH-THE-EXACT-ID-FROM-gh-gpg-key-list'
$ printf 'Selected key: %s\n' "$KEY_ID"
Selected key: REPLACE-WITH-THE-EXACT-ID-FROM-gh-gpg-key-list

4. Warn before deleting the key

Review the command without running it:

$ printf 'About to remove GitHub GPG key: %s\n' "$KEY_ID"
About to remove GitHub GPG key: REPLACE-WITH-THE-EXACT-ID-FROM-gh-gpg-key-list

Do not continue while the placeholder is still there. Check the variable holds one ID with no accidental whitespace or shell expansion. If you cannot identify the key with confidence, this is the point to stop.

5. Delete it with confirmation enabled

Run the command without --yes:

$ gh gpg-key delete "$KEY_ID"

GitHub CLI asks for confirmation. Read the prompt, check the key ID one final time, and confirm only if it matches. Decline and the deletion should not proceed. Exact prompt wording and success output are version-dependent, so treat the exit status as the primary result rather than scripting against a sentence written for humans.

There is no elevated-privilege form of this command. Do not add sudo: root privileges on the Linux machine grant no GitHub account permission and can select a different gh configuration entirely.

6. Verify the account state

List the keys again:

$ gh gpg-key list

Confirm the selected key ID is gone while anything you meant to keep is still there. Still listed: stop rather than repeating the delete command blindly. Check the active account with gh auth status, then compare ID and host with the earlier list.

Deleted the wrong key: there is no local undo in gh gpg-key delete. Recovery needs the original public key material and a deliberate re-add through gh gpg-key add, followed by a fresh listing. Treat that as a new account change: confirm the key and title before submitting, and do not assume re-adding restores every historical association straight away.