GitHub CLI’s Refreshing OAuth Tokens Help Only When Your App and Host Support Them

A token that expires can limit the useful lifetime of a leak, provided the client renews it safely. GitHub CLI 2.103.0 adds an opt-in for expiring OAuth access tokens paired with rotating refresh tokens. Support varies by host version, so the first operational check is whether the CLI is actually using the expected flow.

What changes for gh users

Enable the feature with gh auth login --expiring, or set gh config set expiring_credentials enabled for later logins. GitHub documents support on GitHub.com and ghe.com, and on GitHub Enterprise Server 3.23; earlier GHES versions fall back to non-expiring credentials. The CLI pairs an expiring access token with a rotating refresh token and renews automatically. GitHub says Git 2.46 or later avoids stale credential caching when using gh auth setup-git. ^{[1] [2]}

The general security benefit is familiar: if an access token is copied from a machine, log or backup, a shorter lifetime can limit how long it remains useful. Refreshing changes where the risk concentrates. The refresh credential becomes sensitive long-lived material, and the client must protect it, handle rotation and respond correctly when renewal fails.

GitHub CLI is often used interactively, but it can also appear in build scripts and automation. Interactive refresh may be straightforward for a developer at a terminal. A scheduled job cannot assume a person is present to complete sign-in. Before changing authentication mode on automation hosts, determine whether the job uses a dedicated token, a GitHub App, the built-in Actions token or a user OAuth session. Those are different credential models with different lifetimes and permissions. ^{[2] [3]}

Expiry reduces one risk, not all of them

Shorter access-token validity can reduce the window after accidental exposure. It does not prevent theft, stop a malicious process from using a token while valid, or make an over-scoped credential safe. A token with broad repository or organization permissions remains powerful during its lifetime.

Treat access and refresh credentials as secrets. Do not print authentication state in CI logs, put token values in command-line arguments that process listings can expose, or commit credential files. Use least-privilege credentials for automation and rotate any credential suspected to be exposed. Review the permissions granted during sign-in and the repository scope needed by the task.

The CLI’s automatic refresh is also a reliability path. If the refresh token is revoked or renewal otherwise fails, the user may need to authenticate again. GitHub notes that applications which store a one-time token can break; scripts should obtain a fresh value with gh auth token when needed. Build a visible recovery procedure rather than silently retrying forever or falling back to a broader static token.

Roll it out in a controlled way

Start with a developer account and a non-critical workflow. Enable the option using the documented command, then confirm the host and CLI version. Test renewal and recovery without exposing token values in logs. For Git credential use, GitHub recommends gh auth setup-git; check that the installed Git version is 2.46 or later if you rely on refreshed credentials.

Next, inventory uses of gh auth across machines and automation. Separate interactive developer use from CI and scheduled jobs. For automation, prefer an identity and token type designed for that execution environment, with narrowly scoped permissions and rotation behavior. Test revocation and renewal failure so operators know whether to reauthenticate, recreate an installation token or restore a job.

Finally, document the host and version. On older GitHub Enterprise Server releases the CLI can fall back to non-expiring tokens, so a successful login alone is not evidence of the shorter lifetime. Check the current host behavior before making the security property part of an operational control.

A useful default, with a preview caveat

Expiring credentials with automatic refresh are a useful option: they can reduce the useful lifetime of an exposed access token without forcing constant manual sign-ins. But host fallback behavior and the protection of refresh material still matter.

Teams should adopt it where the host issues the expected token type and the client can protect refresh material. Keep a recovery route, keep permissions narrow, and verify behavior before relying on the expiry promise. The security property comes from the complete authentication flow—not the checkbox alone. For adjacent credential lifecycle patterns, see our explainer on GitHub installation token lifetimes and the risks of leaked cloud build credentials.