Ideas that connect.
Work that moves forward.

What changes

On October 21, 2026, GitHub announced an opt-in public preview of expiring OAuth credentials in GitHub CLI, available from version 2.103.0. GitHub announcement.

When enabled, gh stores a temporary access token alongside a rotating refresh token and refreshes access when needed. GitHub describes access tokens as expiring within hours. Existing sign-ins and manually supplied tokens retain their previous behavior. Authentication documentation.

Availability and server limits

The announcement distinguishes the environments below. The `--expiring` option requests refreshable credentials; if the server does not support them, gh obtains a non-expiring token. Enabling the option alone does not guarantee that the issued token will expire. Announced scope.

Documented activation and configuration

The documentation lists these activation and inspection options. They are presented as documentary references, without execution tests for this article. Authentication guide.

For Git over HTTPS, GitHub recommends using gh as the credential helper and Git 2.46 or later, which allows credentials to be marked so they are not cached beyond their lifetime. Earlier versions continue to work, with an upgrade notice. Version 2.103.0 release notes.

`gh auth setup-git` configures that helper for all authenticated hosts; `--hostname` limits it to one. Review that scope when preparing the test. setup-git manual.

• `gh auth login --expiring`: requests refreshable credentials when signing in.
• `gh config set expiring_credentials enabled`: sets that preference for subsequent sign-ins.
• `gh auth status`: checks authentication status and token expiry.

What scripts need to account for

The official release notes warn that saving the output of `gh auth token` for reuse can leave scripts and extensions holding an expired token. They also specify that tokens supplied through `GH_TOKEN` or `GITHUB_TOKEN` are not automatically refreshed. Release notes.

Calling `gh auth token` again can refresh a supported credential when it has expired or is near expiry, unless `--no-refresh` is used. The command does not update copies already passed to other tools. auth token manual.

Editorial interpretation: trace the credential’s path

Our assessment is that adoption warrants reviewing the complete workflow: which tool needs access, where it obtains the credential, and how long it retains that value. This inventory helps identify who needs to adjust each integration.

For project managers, we propose planning the change by workflow and assigning an owner to each check. The decision can draw on recorded results from a test environment, rather than assuming compatibility is settled by upgrading gh.

Proposed example and outstanding checks

Hypothetical example, not tested: a team saves the output of `gh auth token` to a file in the morning for a nightly task to consume. If the token expires between those times, the task could fail. The proposed alternative is to obtain it close to each use and check whether the receiving tool retains another copy.

Before expanding adoption, we propose the following checks. Their results remain pending. If a workflow depends on a long-lived credential, GitHub advises delaying adoption for that workflow. Announcement recommendation.

• Record the gh and Git versions, target host, and authentication method actually in use.
• Locate scripts, extensions, and tools that store or receive copies of the token.
• In a controlled environment, check a routine operation and repeat it after expiry, documenting refresh behavior and the external consumer’s behavior.