Home / Alt manpages / gh-secret-delete(1)

  • gh-secret-delete(1)
  • User command
  • linux

Delete GitHub CLI Secrets Without Choosing the Wrong Scope

You will remove one GitHub Actions, Dependabot or Codespaces secret with the installed GitHub CLI, after checking exactly where that secret lives. The examples use gh version 2.87.3, installed on this machine. Allow about ten minutes for the checks and the deletion. You need a working gh login and permission to administer the selected repository, environment, organisation or user secret.

Secret deletion is irreversible from this command. The value is not printed before removal and cannot be recovered afterwards. Keep a trusted replacement value or recovery procedure ready before you run the final command.

1. Check the installed command

Start with read-only checks. They do not change GitHub:

$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh secret delete --help
gh secret delete <secret-name> [flags]

The installed help also lists gh secret remove as an alias. Use delete in scripts and notes so the operation is obvious to the next reader. The command accepts one secret name, and the scope is selected by flags.

Checkpoint: confirm that the command is the one you expect:

$ command -v gh
/usr/bin/gh

Your path may differ. The useful check is that it points to the GitHub CLI you intend to use, not to a wrapper or a different installation.

2. Decide which scope owns the secret

Repository scope is the default. It is the right choice for a secret available to Actions runs or Dependabot in one repository. Select a repository explicitly when working outside the current checkout:

$ gh secret delete SECRET_NAME --repo OWNER/REPOSITORY

Replace both uppercase placeholders with real values. The repository form can also include a host, written as HOST/OWNER/REPO, for a GitHub Enterprise installation.

Use the other scope flags as follows:

  • --env ENVIRONMENT deletes a secret for one deployment environment in a repository. Combine it with --repo OWNER/REPOSITORY when the target is not the current repository.
  • --org ORGANISATION deletes an organisation secret. This can serve Actions, Dependabot or Codespaces, depending on the secret's application.
  • --user deletes a secret belonging to your user account. The manual describes these as Codespaces secrets.

Do not use several scope selectors in one command. Choose one scope, then stop and compare it with the place where the secret is actually configured. Similar names at repository and organisation level are separate secrets.

3. Check the application target

Organisation secrets can be associated with a specific application. Use --app when the secret is for one of the applications named by the installed command:

$ gh secret delete SECRET_NAME --org ORGANISATION --app actions
$ gh secret delete SECRET_NAME --org ORGANISATION --app dependabot
$ gh secret delete SECRET_NAME --org ORGANISATION --app codespaces

The accepted values are actions, codespaces and dependabot. An application selector without an organisation target is a distraction trap: before copying it into a script, check the help for the installed version and make sure the scope and application match the secret you intend to remove.

For a repository or environment secret, begin with the smallest command that identifies the scope clearly:

$ gh secret delete SECRET_NAME --repo OWNER/REPOSITORY
$ gh secret delete SECRET_NAME --repo OWNER/REPOSITORY --env production

These examples are destructive. Do not paste them unchanged. Replace SECRET_NAME, OWNER/REPOSITORY and production, then reread the complete command from left to right.

4. Make the deletion deliberate

Before pressing Enter, check four things in the command itself: the secret name, the repository or organisation, the environment if present, and the application if present. Also check your current GitHub account and host if your workflow uses more than one login or server:

$ gh auth status

This is a read-only status check. If it reports the wrong account or host, stop and fix authentication before attempting deletion. Do not work around an authorization error by switching to an account you have not verified.

There is no elevated Linux privilege requirement for gh secret delete. sudo does not grant GitHub permission and can make authentication or configuration harder to understand. Run it as the user whose gh login you have just checked.

5. Run one deletion and record the result

Once the scope is confirmed, run one command only. For example, this targets the production environment in a named repository:

$ gh secret delete DEPLOY_TOKEN --repo acme/widget --env production

The command may print an error if the secret is missing, the selected scope is wrong, the application value is invalid, or your account lacks permission. A successful command returns control to the shell without a useful secret value to display. Treat the exit status as the primary result:

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

Do not interpret a quiet terminal as proof that you selected the intended secret. Record the exact scope and name in your change log, but never record the secret value or an access token.

There is no undo operation for this command. If you deleted the wrong secret, stop dependent workflows and restore it through your normal GitHub secret-management process using a trusted source of the value. If no trusted copy exists, rotate the affected credential and update consumers rather than trying to recover it from shell history or logs.

6. Diagnose a failed attempt

First rerun the help command and compare the flags with the command you used:

$ gh secret delete --help
Delete a secret on one of the following levels:
- repository (default)
- environment
- organization
- user

If the command says that it cannot find a secret, check the spelling and scope. A repository secret and an environment secret with the same name are different targets. If an organisation secret is involved, check the application selector as well. If authentication fails, use gh auth status and correct the account or host rather than repeatedly retrying the deletion.

For a script, fail fast and preserve the exit status:

$ gh secret delete SECRET_NAME --repo OWNER/REPOSITORY
$ status=$?
$ if [ "$status" -ne 0 ]; then
>     printf 'secret deletion failed (status %s)\n' "$status" >&2
>     exit "$status"
> fi

Keep the name and scope as explicit arguments. Avoid building the command from an unreviewed string, especially when secret names or repository names come from an issue, chat message or other untrusted input.

Done means

  • You checked the installed GitHub CLI version and its local help.
  • You selected exactly one scope: repository, environment, organisation or user.
  • You used --repo, --env, --org and --app only where they match the intended target.
  • You verified the authenticated account and host before the destructive command.
  • The deletion returned exit status 0, and the secret value was never copied into notes or logs.
  • You have a trusted restoration or credential-rotation path because deletion cannot be undone by gh secret delete.