Delete a GitHub Repository with gh repo delete

gh repo delete removes a GitHub repository for good, and there is no local Git command that can bring it back afterwards. Spend a few minutes checking the target and any backup before the final command; the deletion itself takes seconds.

This guide matches the installed GitHub CLI 2.87.3, released in February 2026. The local manual documents gh repo delete [<repository>] [flags], the --yes flag and the required delete_repo authorisation scope. It also documents a safety rule that is easy to miss: omit the repository argument, and --yes is ignored, so an interactive confirmation still appears.

Before you start

1. Install and authenticate gh for the GitHub account or organisation that owns the repository.
2. Write down the exact repository name in OWNER/REPOSITORY form. Do not paste a name from an untrusted issue, shell variable or chat message without checking it first.
3. Check that you have an independent copy of anything you may need. A clone preserves Git objects, not issues, pull requests, discussions, releases, settings or repository secrets.

No root access or sudo is needed. The operation changes the remote GitHub repository through the account's own authorisation.

1. Confirm the installed command

Check the version and read the command's local help. This catches a different binary earlier in PATH, and shows the behaviour of the version you are about to use.

$ gh --version
gh version 2.87.3 (2026-02-23)

$ gh repo delete --help

2. Check authentication before the destructive step

Ask gh which account and host it is using. Do not infer this from the repository's remote URL: GitHub CLI credentials and Git remotes can point at different accounts.

$ gh auth status
Logged in to github.com account EXAMPLE_ACCOUNT (keyring)
  ✓ Logged in to github.com account EXAMPLE_ACCOUNT
  ✓ Git operations for github.com configured to use https protocol.
  ✓ Token scopes: ...

The exact status text varies, but the account must be the intended one, and the token needs the delete_repo scope. If it does not have it, refresh the scope deliberately:

$ gh auth refresh -s delete_repo

This may open a browser or ask for a one-time authorisation. A missing scope is an authorisation problem, not a reason to try a different repository name or add sudo.

3. Inspect the exact target

Use the fully qualified name for the final operation. Inspect it first without changing anything:

$ gh repo view EXAMPLE_OWNER/EXAMPLE_REPOSITORY

Check the owner, repository name, visibility and description in the output. If the command reports that the repository cannot be found, stop: a typo, a different account, insufficient visibility or an organisation policy can all cause that, and none of them justifies guessing.

Inside a local checkout, you can see which repository gh would use with no argument supplied:

$ gh repo view

That shortcut is fine for inspection, but avoid it for deletion. Without an argument the command depends on the current directory and its Git remote, and an accidental directory change becomes a dangerous distraction.

4. Make a last backup check

Before deletion, verify the copy you intend to keep. For Git data, a mirror is more complete than a working clone:

$ git clone --mirror https://github.com/EXAMPLE_OWNER/EXAMPLE_REPOSITORY.git EXAMPLE_REPOSITORY.git
$ git -C EXAMPLE_REPOSITORY.git fsck --full

Use an existing, trusted backup if one already meets your needs. Do not put a token into the URL or save credentials in a shell history merely to create this copy. Git data still does not cover GitHub-hosted metadata such as issues or repository settings.

5. Delete by explicit name

Once the target is checked and you accept the loss, pass the exact OWNER/REPOSITORY value and use --yes:

$ gh repo delete EXAMPLE_OWNER/EXAMPLE_REPOSITORY --yes

The explicit repository name is what makes this safe: in GitHub CLI 2.87.3, --yes is honoured only for an explicitly named repository. Omit the repository and this version ignores --yes and prompts anyway. That behaviour stops a non-interactive command in the wrong checkout from deleting the checkout's current repository, but it is no substitute for checking the name yourself.

A successful deletion normally returns to the shell without a substantial message, so treat the exit status as your first result:

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

If the command fails, keep the repository name and error text. A non-zero status means you should not assume deletion happened; verify the remote state before retrying.

6. Verify the remote state

Ask GitHub CLI to view the repository again:

$ gh repo view EXAMPLE_OWNER/EXAMPLE_REPOSITORY
GraphQL: Could not resolve to a Repository with the name 'EXAMPLE_REPOSITORY'. (repository)

The exact error wording can change; what matters is that the repository no longer resolves for the account. You can also test the Git endpoint without touching local files:

$ git ls-remote https://github.com/EXAMPLE_OWNER/EXAMPLE_REPOSITORY.git
fatal: repository 'https://github.com/EXAMPLE_OWNER/EXAMPLE_REPOSITORY.git/' not found

A local clone still being present is not evidence that deletion failed. Deleting the GitHub repository does not erase your local directory; keep it as a source for rebuilding elsewhere if that is part of your recovery plan.

Common failure modes

• Missing delete_repo scope: run gh auth refresh -s delete_repo for the intended account, then repeat the inspection. Scope refresh can require web authorisation.
• Repository not found: compare the owner and name character by character, check gh auth status, and confirm the host. Do not add a guessed organisation prefix.
• Confirmation appears unexpectedly: the repository argument was omitted, so the installed CLI ignored --yes. Cancel with Ctrl-C, inspect the checkout, then use the explicit name only if it is correct.
• Deletion succeeded but a local command fails: local Git data and GitHub's remote repository are separate. Keep the local clone, and create a new remote only after deciding how much metadata must be recreated.