Safely Remove a GitHub Deploy Key with gh

You will remove one deploy key from the intended GitHub repository, using its numeric key ID, and verify that it is gone. This is a destructive repository administration action: the command removes the key from GitHub and does not offer a confirmation flag or an undo operation.

Allow about ten minutes. You need GitHub CLI, an authenticated account with administration write permission for the repository, and the repository's owner/name. The examples use the executable installed here, which reports GitHub CLI 2.87.3 (23 February 2026). Your output may differ if another version is on your PATH. No command in this guide needs sudo.

1. Check the command you will use

Read the local command help before making any change:

$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh repo deploy-key delete --help
Delete a deploy key from a GitHub repository

USAGE
  gh repo deploy-key delete <key-id> [flags]

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

The delete subcommand has one required argument, key-id, and only inherits --repo and --help. In particular, do not add --yes: this command does not define it. The command sends the deletion request immediately after the target and credentials have been accepted.

2. Choose the repository explicitly

Do not rely on the current directory's repository when deleting a security credential. Set the target as a shell variable, then inspect it before using it:

$ REPOSITORY='OWNER/REPOSITORY'
$ printf 'target repository: %s\n' "$REPOSITORY"
target repository: OWNER/REPOSITORY

Replace both placeholder words with the real owner and repository name. For a GitHub Enterprise host, use HOST/OWNER/REPOSITORY. The -R option selects that repository for this invocation and is the inherited option documented by the local manpage.

Check authentication without changing repository state:

$ gh auth status

Confirm that the reported account and host are correct. A successful login alone does not prove that the account can administer this repository. If the command reports authentication is required, authenticate through your normal GitHub CLI process before continuing.

3. Find the exact deploy-key ID

List the keys for the chosen repository. Use JSON so the identifier and title are easy to compare:

$ gh repo deploy-key list -R "$REPOSITORY" --json id,title,key,readOnly
[{"id":123456789,"title":"deploy-prod","key":"ssh-ed25519 AAAA...","readOnly":true}]

The list command documents id, title, key and readOnly as available JSON fields. The ID is the value to pass to delete, not the title, fingerprint, public-key text or a file name. Treat the example number above as a placeholder: copy the ID from your own output.

Compare three things before proceeding: the repository in REPOSITORY, the key title, and enough of the public key to identify the intended credential. If more than one entry looks plausible, stop and resolve the ambiguity. A deploy key grants access to one repository, and deleting the wrong one can interrupt a deployment or another automated job.

$ KEY_ID='123456789'
$ printf 'deleting key ID %s from %s\n' "$KEY_ID" "$REPOSITORY"
deleting key ID 123456789 from OWNER/REPOSITORY

4. Delete the key

Read the warning, then run the command only when the printed target and ID match your notes:

$ gh repo deploy-key delete "$KEY_ID" -R "$REPOSITORY"
$ printf 'delete exit status: %s\n' "$?"
delete exit status: 0

The local exit-code documentation defines status 0 as successful execution, status 1 as an error, status 2 as cancellation, and status 4 as authentication required. A successful command normally has no useful response body because GitHub's delete endpoint returns no content. If the terminal is interactive, this version may print a short success message; do not use that message as your only verification.

There is no elevated-privilege variant. sudo gh ... would change which user's configuration and credentials are read, and it would not grant GitHub permission. Keep the operation under the account you checked in the previous step.

5. Verify that the key is absent

List the repository's deploy keys again and look for the ID you removed:

$ gh repo deploy-key list -R "$REPOSITORY" --json id,title
[]

An empty array is expected when that was the repository's only deploy key. If other keys remain, confirm that KEY_ID is not present. A list request that fails is not proof that deletion failed: check the error, host, repository spelling and authentication, then repeat the read-only list command.

Deleting the GitHub record does not erase a private key file from a server, workstation or secrets store. It does stop that deploy key from authenticating to this repository. Search the systems that used it and retire the corresponding private key according to your operational process. Do not paste private-key material into shell history, issue comments or support requests.

Recovery and common traps

Deletion is not reversible through gh repo deploy-key delete. GitHub treats deploy keys as immutable: if access must be restored, create a new key pair, or re-add the retained public key with its title, using the add workflow and a deliberate review. Do not assume that regenerating a personal access token restores a deploy key; token and deploy-key behaviour depends on how the key was created.

• Wrong repository: always pass -R explicitly when the action matters, especially from a directory with a different Git remote.
• Wrong identifier: obtain id from gh repo deploy-key list. A title is not a key ID.
• Unexpected option error: this installed delete command has no --yes or force flag. Check its help rather than guessing a flag.
• Permission failure: the GitHub API requires repository administration write permission for deletion. Ask a repository administrator or use the correct authenticated account.
• Automation breakage: search deployment configuration and hosts for use of the key before deleting it, or schedule replacement first.