GitHub CLI 2.103.0 Adds Expiring OAuth Tokens: Setup, Git HTTPS and Script Compatibility

GitHub says that once you opt in, gh stores an expiring access token and a rotating refresh token. It refreshes the token when needed. A leaked access token then stops working within hours instead of lasting indefinitely.

The change is small to turn on. It does need a quick check of any scripts or tools that save a token and reuse it later.

How to opt in​

You need v2.103.0 or later. There are two ways to opt in:

• For one login: run gh auth login --expiring.
• For every login: run gh config set expiring_credentials enabled. After that you don't need the flag.

After opting in, there is nothing extra to run day to day. gh handles refreshes in the background. To see the state of an expiring credential, including when the current access token expires, run gh auth status.

The official CLI manual describes --expiring as a preference, not a guarantee. Whether you get an expiring token depends on the host and the OAuth app configuration. A host without support issues a normal token. The manual also notes that a host configured for expiring tokens may issue them even without the flag.

The manual also documents --expiring=false. It requests a non-expiring token even when expiring_credentials is enabled. That is the escape hatch for a machine or workflow that can't handle expiry yet.

Git over HTTPS: set up the credential helper​

If you use Git over HTTPS, GitHub strongly recommends two steps.

1. Make gh your Git credential helper with gh auth setup-git. gh then supplies and refreshes the credential for Git, so Git doesn't keep a stale token.
2. Use Git 2.46 or newer. That version lets gh mark expiring credentials so they aren't cached past their lifetime. Older Git versions still work, but gh prints a one-time recommendation to upgrade.

The CLI manual spells out the risk. With an older Git, a credential-caching helper may store and reuse an expired token. If you see authentication failures that appear and disappear, check which credential helper Git is using. Also check how old your Git is.

On a Windows machine, check which helper Git uses before you opt in. Confirm that gh is the one answering. The announcement doesn't say SSH-based Git authentication needs any of these steps.

What can break​

Short-lived tokens break anything that captures a token once and reuses it later. GitHub names two cases:

• Scripts and extensions that run gh auth token and store the result.
• Tokens copied into another tool.

Those saved copies will eventually expire. The fix is to read the token fresh each time with gh auth token. GitHub says that call refreshes the token when needed instead of returning a cached value. If a workflow needs a token that stays valid for a long time, GitHub advises not opting in for that workflow yet.

A practical audit before enabling this widely:

• Search shell profiles, scheduled tasks, and scripts for gh auth token.
• Look for tokens pasted into other tools' settings or environment variables.
• Check any extensions that cache credentials.
• Confirm that HTTPS Git users have run gh auth setup-git.

The announcement doesn't say every workflow that uses gh auth token will fail. Workflows that fetch a fresh token each time they run should keep working. This audit is my own reading of GitHub's stated expiry behavior.

Where it works​

Expiring tokens are available today on github.com and ghe.com. GitHub Enterprise Server issues them starting with GHES 3.23. On earlier GHES versions, opting in quietly falls back to the old non-expiring behavior. So a mixed fleet of hosts won't produce errors, but it also won't give you the protection on older servers.

GitHub's earlier platform changelog shows the likely model. Hmm, that search result is unrelated Rather than rely on it, here is what GitHub said on August 14, 2026 about OAuth apps in general. An opted-in app gets an access token that lasts eight hours and a refresh token valid for six months. The app uses the refresh token to get a new pair when the access token expires. That post also says these changes will be in GHES 3.23. It does not state the exact lifetimes for GitHub CLI tokens, so don't assume they match.

What's next​

GitHub says it plans to make expiring credentials the default for new sign-ins in a future release. It gave no date. Existing sign-ins and manually supplied tokens keep working as before, and nothing changes unless you opt in. Treat the preview as a chance to find fragile token handling now, before the default flips.

Bottom line​

• Upgrade to gh v2.103.0 or later.
• Opt in with gh auth login --expiring, or set expiring_credentials to enabled.
• Run gh auth setup-git if you use Git over HTTPS, and move to Git 2.46 or newer.
• Audit anything that stores the output of gh auth token.
• Check token expiry with gh auth status.

The tradeoff is a bit of upfront work for a much smaller exposure if a token leaks.