Get the Right GitHub Token with gh auth token

A script needs a GitHub token, and gh auth token hands it over: print it carelessly and it lands in your shell history. You will identify which credential gh would use, then pass that token to one command without ever printing it. Allow about ten minutes. You need GitHub CLI installed and an account already authenticated with it. The examples use gh 2.87.3, installed on this machine in September 2026.

1. Confirm the installed command

Check the executable and its local help first. These are ordinary read-only commands and need no sudo:

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh auth token --help
This command outputs the authentication token for an account on a given GitHub host.

The command is gh auth token. It prints the credential itself, not a masked status line. Treat every invocation as a security-sensitive operation.

2. Check the account and host without revealing the token

Before asking for the token, confirm the account that is active for the host. This keeps a common mistake visible: a host can have more than one authenticated account, and the active one is used whenever you omit --user.

$ gh auth status --active --hostname github.com
github.com
  ✓ Logged in to github.com account ACCOUNT_NAME (keyring)
  ✓ Git operations for github.com configured to use https protocol.

• Use your own hostname. Replace github.com with your GitHub Enterprise Server hostname when needed, and do not copy the sample account name as a real value.
• No active account? Authenticate or select one with the normal gh auth workflow before continuing.

Checkpoint: write down the exact hostname and account you intend to target. If you do not know the account, stop here and resolve that first.

3. Select the host explicitly

For the default public GitHub host, this asks for the active account's token:

$ gh auth token --hostname github.com

That command prints a live secret. Do not run it in a shared terminal, screen recording, build log or shell history review session, and never paste the output into a ticket or chat. There is no elevated-privilege requirement, and the command does not change the stored authentication configuration.

For an enterprise host, name it exactly:

$ gh auth token --hostname github.example.com

The hostname is not a label or repository owner. It is the GitHub host that gh holds authentication data for.

4. Select a non-active account

If several accounts are stored for one host, pass the account name with --user or its short form -u:

$ gh auth token --hostname github.com --user ACCOUNT_NAME

Use the exact account identifier shown by gh auth status. This is one of the host's authenticated accounts, not a GitHub organisation, repository owner or email address, unless the status output identifies it that way. Check your selection without requesting a token:

$ gh auth status --hostname github.com
github.com
  ✓ Logged in to github.com account ACCOUNT_NAME (keyring)

5. Pass the token to one command without displaying it

If a script needs the token, keep it in the environment of the single child process that needs it. This asks gh auth token for a named account and gives the result to gh api with no echo, file or visible command argument:

$ GH_TOKEN="$(gh auth token --hostname github.com --user ACCOUNT_NAME)" \
  gh api --hostname github.com user --jq '.login'
ACCOUNT_NAME

• Still sensitive in flight. The token exists while the shell expands the command and while gh api runs, so keep the terminal private.
• No tracing. Do not run set -x against this script, and do not wrap it in anything that logs.
• Safe output. The command's own output is the account login, not the token, so it is fine for a simple identity check.

For automation, prefer the documented environment variables, such as GH_TOKEN for github.com or GH_ENTERPRISE_TOKEN for an enterprise host. They take precedence over stored credentials for the relevant host, which is useful, but it can also be exactly why changing the stored account appears to do nothing.

6. Diagnose the usual wrong-account result

If a command uses the wrong identity, inspect the environment and active account first, rather than printing tokens repeatedly:

$ env | grep -E '^(GH_TOKEN|GITHUB_TOKEN|GH_ENTERPRISE_TOKEN|GITHUB_ENTERPRISE_TOKEN|GH_HOST)=' \
  | sed 's/=.*$/=[set]/'
$ gh auth status --active --hostname github.com

The first command reveals only variable names and whether they are set. Do not remove or replace a variable blindly, since another job may depend on it: if one is set, it may intentionally override stored credentials. If none is set, recheck the active account and hostname. For a host that is not github.com or a ghe.com subdomain, use the enterprise token variable documented for that host.

7. Recover after accidental exposure

Security warning: if the token appeared in a log, terminal recording, process capture or shared shell, treat it as compromised. Do not rely on clearing the screen or deleting shell history. Remove the local account with gh auth logout if appropriate, then revoke the GitHub CLI authorisation or rotate the credential through your organisation's process. Logging out only removes local configuration; it does not revoke tokens already issued.

$ gh auth logout --hostname github.com --user ACCOUNT_NAME

Confirm the host and account before running that command. It changes local authentication state, so it is deliberately not part of the normal read-and-use workflow. Re-authenticate later with your approved method if the account is still needed.

Done means

• Version and host checked. The installed gh version and target host were confirmed.
• Account identified. gh auth status named the intended active or named account without printing a token.
• Host named when needed. --hostname was used whenever the target was not the default host.
• Right account selected. --user was used whenever the active account was not the intended one.
• Token kept private. It stayed out of terminal output, files, logs and command arguments where possible.
• Exposure handled properly. Any accidental leak was treated as a credential incident, with local logout and revocation done separately.