Delete a GitHub Issue Safely with gh issue delete

You will finish with a checked command for permanently deleting one GitHub issue from the intended repository. The examples use GitHub CLI version 2.45.0, installed here as the Debian package gh 2.45.0-1ubuntu0.3+esm3. Allow about ten minutes for the checks. You need the gh command, an authenticated GitHub account with permission to delete issues, and the repository name or a local checkout connected to it.

1. Check the installed command

Start with the local help output. This is read-only and confirms the command shape and the flags available in the installed version:

$ gh --version
gh version 2.45.0

$ gh issue delete --help
Delete issue

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

FLAGS
  --yes   Confirm deletion without prompting

The required argument is one issue number or one issue URL. The command does not accept a list of numbers. The inherited -R or --repo option selects a repository in [HOST/]OWNER/REPO form.

2. Identify the repository and issue

Do not begin with --yes. First make the repository explicit, then inspect the issue. An issue number is meaningful only within a repository, so the explicit form is safer for scripts and terminals open in the wrong directory:

$ REPO='OWNER/REPOSITORY'
$ ISSUE_NUMBER='123'
$ gh issue view "$ISSUE_NUMBER" --repo "$REPO"
title: Replace the temporary deployment key
state: OPEN
author: example-user
labels: maintenance
comments: 2
assignees: example-user

Replace both placeholders with real values. The displayed title, state and author are your checkpoint: stop if they do not identify the issue you intended to remove. gh issue view only reads the issue. It does not reserve the number, so check again immediately before deleting if other people can edit the repository.

A full URL is also accepted and can make a copied ticket unambiguous:

$ gh issue view 'https://github.com/OWNER/REPOSITORY/issues/123'

Do not copy a pull request URL into this workflow. GitHub displays pull requests in the issues interface, but a pull request is a different object. The delete command checks the target and refuses a pull request rather than deleting it as an issue.

3. Run the confirmation-protected deletion

With the target checked, run the command without --yes first:

$ gh issue delete "$ISSUE_NUMBER" --repo "$REPO"
Deleted issues cannot be recovered.
? Are you sure you want to delete issue #123? (y/N)

Read the repository and issue number shown by the prompt. Confirm only when they match your checkpoint. If you answer no, the command stops without deleting the issue. In an interactive terminal, the command warns that deleted issues cannot be recovered before asking for confirmation.

When the deletion succeeds, gh returns a successful exit status. If the terminal is interactive, the installed command reports the repository, number and title after the API request. The exact terminal formatting can vary with colour settings, so use the status code and a fresh read check as the reliable verification points.

4. Use --yes only after an equivalent check

--yes skips the prompt. It is useful for a reviewed one-off command or an automation job, but it removes the last pause before an irreversible change:

$ gh issue view "$ISSUE_NUMBER" --repo "$REPO" > /tmp/issue-before-delete.txt
$ gh issue delete "$ISSUE_NUMBER" --repo "$REPO" --yes
$ status=$?
$ printf 'delete exit status: %s\n' "$status"
delete exit status: 0

The temporary file is an optional local record of the details you reviewed. It is not a backup: it does not preserve the issue body, comments, attachments or event history. Remove it after your normal retention period if it contains information that should not remain on the machine.

For a script, keep the repository and issue variables quoted and fail on a non-zero status:

set -u
REPO='OWNER/REPOSITORY'
ISSUE_NUMBER='123'

gh issue view "$ISSUE_NUMBER" --repo "$REPO" > /tmp/issue-before-delete.txt || exit $?
gh issue delete "$ISSUE_NUMBER" --repo "$REPO" --yes

This performs a read immediately before the deletion, but it cannot make the operation transactional. An administrator or another automation process can still change the issue between the two API requests. For high-consequence work, make the final review and deletion a human-controlled step.

5. Verify the result and handle failures

After a successful deletion, ask GitHub for the same issue:

$ gh issue view "$ISSUE_NUMBER" --repo "$REPO"
Could not resolve to an Issue with the number of 123.
$ printf 'view exit status: %s\n' "$?"
view exit status: 1

The wording can differ between GitHub hosts and CLI releases, but the important result is that the read fails because the issue no longer exists. If the view command still returns the issue, stop: you may have used a different repository, a different host, or an issue number that was not the target.

A failed delete command is not proof that nothing changed. Network failures can occur after the server has processed the request. Re-run the read-only gh issue view check before attempting anything again. Permission errors mean the authenticated account cannot perform the operation; do not work around them by switching credentials without an explicit access decision. Authentication problems can be inspected with gh auth status, which does not change repository data.

There is no undo command in the manpage, and the API deletion is not reversible through this command. If the issue was deleted by mistake, recovery means recreating the issue from whatever external records, notifications or exports you retained. The temporary view output above is only a small audit note, not a recovery mechanism.