Check Scripts That Store gh auth token Before You Opt In to GitHub CLI Expiring OAuth Tokens

How do expiring OAuth tokens differ from the existing login?

According to the GitHub changelog of 2026-10-21, gh stores a short-lived access token together with a rotating refresh token. Each time the access token expires, gh swaps in a new one in the background, and a new refresh token is issued at the same time.

What changes is how long a leaked token stays useful. A regular token stays valid until you revoke it, while an expiring access token becomes unusable within hours. Neither the changelog nor the docs gives the exact lifetime as a number.

How do you turn it on and check its status?

There are two ways to opt in, and both need gh v2.103.0 or later.

Sources are the changelog above and the GitHub CLI authentication docs, checked on 2026-10-27.

After opting in, gh auth status shows whether the credential is refreshable and when the current access token expires. It can also refresh a token that is close to expiring. Add --no-refresh if you only want to read the status.

When you change scopes with gh auth refresh --scopes <scopes>, pass --expiring too or keep the setting on. According to the docs, otherwise the expiring credential can be replaced by a regular one. The background refresh does not change scopes.

What do you need so git push does not break?

If you use git over HTTPS, gh has to act as the credential helper, so that it can hand git a refreshed token each time git asks. If you have not set that up, run gh auth setup-git. Signing in with expiring credentials also prompts you about it.

Git 2.46 or newer is recommended. From that version, gh can stop a caching helper from holding on to a credential past its lifetime. Older versions still work, but you see a one-time upgrade recommendation. Run git --version first to see what your team's machines use.

For environments that use git only over SSH, the docs do not say whether this part applies. That is not confirmed, so sort out which repos use HTTPS first.

Which scripts and automation can break?

The changelog says not to save the output of gh auth token and reuse it later, because the saved token eventually expires. Call gh auth token each time you need one, and gh refreshes it first when needed. If you want the current value without refreshing, there is --no-refresh.

The checklist below is a suggested order, not a procedure from the official docs.

1. Search your repos and personal scripts for gh auth token and find places that move its result into a file, an environment variable, or a secret store instead of a variable.
2. Mark places where that token is copied into another tool's settings, such as a cache file or a container build argument.
3. Keep jobs that need a long-lived token out of the opt-in for now. The changelog also says not to opt in yet for a workflow that depends on a token that stays valid for a long time.

Tokens passed through GH_TOKEN or GITHUB_TOKEN are not expiring tokens and are not refreshed. The release notes state that those environment-variable tokens are never refreshed. The changelog does not cover how CI uses them, so leaving CI settings as they are is the safer choice.

Where can you use it in your environment?

It works today on github.com and GHE.com. If a server does not support expiring credentials, --expiring falls back to a regular token and shows a message saying so. The changelog says GitHub Enterprise Server is supported from GHES 3.23, while the limitations in the authentication docs list only GitHub.com and GitHub Enterprise Cloud. If you run an internal server, check the docs for your version first.

The changelog says expiring credentials will eventually become the default for new sign-ins, but gives no date. For today, there is one task: search your team repos for gh auth token and list every place that stores it. If there are none, try gh auth login --expiring on a single development machine first. Checked on 2026-10-27.