GitHub CLI expiring OAuth preview: audit the lifetime of copied tokens

Your CLI remains signed in, yet a helper that started yesterday suddenly fails. Before repeating the login, ask whether the helper still holds a token copied earlier. A credential manager can refresh its own state without updating every string another process has retained. GitHub’s October 21, 2026 announcement of expiring OAuth credentials in GitHub CLI makes that boundary operationally important. The useful first deliverable is a map of credential consumers, rather than a count of successful sign-ins.

Confirmed change: refreshable credentials remain opt-in

The announcement introduces gh auth login --expiring starting with v2.103.0. The CLI stores an expiring access token with a rotating refresh token and renews it when needed. Existing sign-ins and manually supplied tokens retain their behavior. Servers without support can fall back to nonexpiring credentials; supported hosts are github.com, ghe.com, and GHES 3.23 or later. Record the actual state from gh auth status instead of treating the presence of a flag as proof that a short-lived credential was issued.

Operational interpretation: a copied string does not refresh itself

GitHub specifically warns about scripts that capture gh auth token once and reuse the result later. External consumers should obtain a fresh value when needed. For a team, the diagnostic question is whether each consumer calls gh again or repeatedly reads its original copy. A successful read at process startup cannot demonstrate validity at a later step of a long-running task. Likewise, a shorter access-token lifetime should not be interpreted as eliminating the consequences of a compromised refresh token. This is a review of the credential lifecycle, not a claim that renewal replaces least privilege or revocation.

A review sequence a team can adopt

First inventory the installed gh version, host, and consumers that copy credentials into files, environment variables, or extensions. Inventory ownership and retrieval timing without collecting token values. Then use a nonproduction environment to compare the same harmless read shortly after startup and again later. Separate expiration errors from missing permissions and network failures; otherwise an unrelated outage may look like a refresh regression. For HTTPS git, review the official recommendations to configure gh auth setup-git and use git 2.46 or later. Treat any actual configuration change as a separately reviewed operation. Reading this article does not change a reader’s credentials or settings.

Some paths need migration work before opting in

An integration built around a long-lived token may be a valid reason to defer this preview for that workflow, as the announcement itself explains. Give the exception an owner, a consumer path, and a review date so that deferral does not become invisible debt. Do not replace developer OAuth and CI GITHUB_TOKEN credentials as though they were interchangeable. One login flag does not standardize permission scope, expiration, and revocation across every automation. Because this remains a public preview, check current host support and the help for the version actually installed before planning a rollout.

“Staying logged in” is useful shorthand in developer discussions, but an implementation review needs two answers: can the owner refresh the credential, and does the consumer receive the refreshed value? This article does not measure community failure rates or adoption results. At the next operational review, draw one real consumer path and mark who owns its cache. A clear boundary makes a small trial easier to evaluate and a later failure easier to reproduce.

Official sources and further checks

GitHub Changelog · Expiring OAuth preview

GitHub Docs · CLI authentication

Keep version, host, cache ownership, retrieval timing, and test results in the team record; omit all secret values.