GitHub CLI’s expiring tokens trade durable secrets for refresh-aware tooling

What Changed

Source report Developers can opt in during sign-in with gh auth login --expiring or make the preference persistent with gh config set expiring_credentials enabled. GitHub says the CLI stores an expiring access token with a rotating refresh token and refreshes automatically when needed. Existing sign-ins are unchanged, and unsupported hosts fall back to a conventional nonexpiring credential. [1]

The option is intentionally not a guarantee. The CLI manual says issuance depends on the host and OAuth configuration. For Git over HTTPS, GitHub recommends Git 2.46 or newer and configuring gh as the credential helper. [2] [3]

Why It Matters

Analysis The security gain is bounded: a stolen access token becomes less durable, but a stolen refresh token or compromised workstation still demands revocation and investigation. Adoption should therefore be framed as credential-lifetime reduction, not a substitute for endpoint security, least privilege or secret detection.

The largest compatibility risk is token extraction. Extensions and scripts that run gh auth token once, persist the result and reuse it later will eventually receive authentication failures. GitHub’s guidance is to read the token fresh for each use. Teams should map those consumers before changing the default for a broad developer population.

Evidence & Uncertainty

The preview behavior, minimum CLI version and platform coverage come directly from GitHub. The announcement says a leaked access token becomes unusable within hours, but does not specify an exact duration. It does not establish refresh-token rotation behavior under every failure mode or quantify the reduction in account compromise. Security benefit depends on how quickly leaked credentials are detected and whether downstream tools honor refresh semantics.

Because the feature is opt-in and backward compatible, a controlled pilot can produce local evidence: authentication error rates, cached-token findings, Git version coverage and help-desk volume. That is more useful than assuming every workflow behaves like an interactive terminal.

Choose the credential path before opting in

Practical analysis The migration decision is per workflow, not per account. A successful interactive sign-in does not prove that a scheduled job, an HTTPS Git client and an extension all use the same credential path. The checks below are proposed tests, not results from a BriefSpire pilot.

Check the credential source first. For github.com and ghe.com subdomains, GH_TOKEN takes precedence over GITHUB_TOKEN, and these variables override stored credentials. GHES has corresponding enterprise-token variables. Inspect whether overrides are present without printing their values. Do not assume a manually supplied token gains automatic refresh from this opt-in. GitHub CLI environment reference.

A pilot that can demonstrate refresh

Proposed validation Record the CLI and Git versions, host, account, credential source, helper configuration and initial expiry. Use gh auth status --hostname HOST --no-refresh when observing expiry without triggering a refresh. Ordinary gh auth status can refresh an expired or near-expiry credential itself. Keep --show-token out of evidence captures. Status behavior.

After the recorded expiry, repeat the actual read operation through the path being evaluated. Record its result and the subsequent credential state, with secrets redacted. A successful command before expiry is only a baseline; a command using a different token is not evidence of this refresh path. For failures, separate host/account selection, credential caching, permissions and connectivity before attributing the cause to expiry.

Recovery: Have the account owner available to reauthorize the intended host if refresh cannot recover. A revoked token cannot be restored; GitHub documents obtaining new credentials after revocation. Suspected exposure calls for revocation and investigation rather than waiting for expiry. Expiration and revocation guidance.

Testing disclosure: BriefSpire has checked the cited documentation but has not independently tested this preview or completed the pilot described here. No success rate, compatibility result or security outcome is claimed.

Story Timeline

• October 21, 2026: GitHub announced the public preview for CLI 2.103.0.
• Availability in the announcement: github.com and ghe.com can issue refreshable credentials; GHES support starts with 3.23.
• Planned change: GitHub said it intended to make expiring credentials the default for new sign-ins; the announcement specified no rollout date.

Related Reading

GitHub’s temporary clone restrictions make CI authentication a reliability decision — both changes show why CI and developer authentication need an explicit fallback and ownership model.