GitHub CLI introduced an opt-in public preview of expiring, automatically refreshed OAuth credentials. The login option starts with gh 2.103.0; it does not immediately replace every existing sign-in. GitHub official announcement
A script that copies a token once may retain it after expiry even while gh can refresh its own credentials. Find workflows that save token strings to files or reuse them for long periods.
On this page
Access tokens and refresh tokens have different jobs
An access token authorizes API calls; a refresh token participates in obtaining a new access token. Expiration can reduce how long a leaked access-token value remains usable. Refresh tokens and the local credential store still require protection. A short lifetime is an additional control, not a replacement for narrow permissions and careful storage of credentials.
When the CLI manages refresh, users can continue working without logging in repeatedly. That does not automatically replace a token string already copied into another program. A script keeping the value in a file or long-lived environment can work initially and fail later. Review both when the credential is obtained and when each consumer actually uses it.
Review the Git authentication path as well
An API request made through gh and a Git transfer over HTTPS can follow separate credential paths. If Git retains an old value in another cache, refreshing inside gh alone may not solve the problem. This is why the official guidance recommends configuring gh as Git’s credential helper. Record SSH-based Git access separately because it uses a different authentication mechanism.
A request for expiring credentials can fall back to the existing behavior when the server does not support them. Successful login therefore does not prove that the credential is expiring. Confirm gh and Git versions, the destination host and server capabilities, and the credential’s actual expiration information before recording the transition as complete.
Test later use as well as the first successful request
Use the following commands to inspect versions and authentication state, then choose a separate user environment for evaluating opt-in login under the official instructions. Test read operations immediately and again later through both CLI and Git paths. Do not print raw tokens into shared terminals or logs as a shortcut for checking their behavior.
For long-running automation, consider a task-appropriate app identity or approved authentication design rather than repeatedly copying a person’s interactive credential. Scripts maintaining their own token cache need explicit expiry handling and renewal ownership. Start the preview with consumers whose behavior is understood and whose migration can be validated without leaving unknown credential copies behind.
gh --version
git --version
gh auth statusThese commands inspect the current state. Apply opt-in login and Git credential-helper configuration only after checking the conditions in the linked official guidance.
Checks before opting in
- Verify actual gh and Git versions and server support.
- Find scripts and extensions that cache one retrieved token.
- Test credential-helper use and unattended workflows separately.
Shorter token lifetimes and durable automation need to be designed together. Do not mistake a fallback on an unsupported server for a completed migration.
Announcement reference date: 2026-10-21 · Checked: October 24, 2026
.jpg){kind=link}