Updated October 22, 2026. Based on the official announcement linked below.
Shorter-lived credentials can reduce the useful lifetime of a copied access token. They can also expose an old assumption in a script: that a value captured once will keep working indefinitely. GitHub CLI’s new opt-in preview makes this a good moment to inspect how your own workflow obtains credentials.
What GitHub announced
GitHub’s October 21 changelog introduces expiring, automatically refreshing OAuth credentials in public preview. Starting with GitHub CLI 2.103.0, the documented login option is gh auth login --expiring. The CLI stores a rotating refresh token alongside the access token and handles refresh when needed.
GitHub warns that scripts which capture a token and reuse it later can fail when that value expires. It recommends its credential helper for Git over HTTPS and documents support differences across GitHub.com, ghe.com, and Enterprise Server versions. Read the full notice before changing a shared workflow.
Inventory where the credential goes
List the tools and scripts that use your GitHub CLI sign-in. Separate interactive commands from jobs that extract a token and pass it elsewhere. Record the person responsible for each integration.
Do not print credentials into a shared worksheet or paste them into a support conversation while doing this inventory. You need to document the flow, not expose the secret value.
Find assumptions about token lifetime
Look for a setup step that saves one token for later use. Ask whether the receiving tool can obtain a fresh credential through the supported mechanism or expects a permanent value.
A hypothetical daily report might work immediately after setup and then fail because it reuses an old captured credential. The important debugging question is where the token came from and whether refresh is part of the supported path, not simply whether the user can still sign in interactively.
Test a bounded workflow first
Choose a non-production task and use the official instructions for your supported CLI and server versions. Record the previous working configuration so the team can understand what changed.
Check one normal interactive action and one representative automated action. Verify that the automation runs under the intended identity and that its credential handling matches the documented approach. Keep test output free of secret values.
Keep Git and other consumers distinct
A successful CLI command does not prove that every external consumer handles the credential correctly. Review how Git over HTTPS obtains its credential, and follow GitHub’s helper guidance where it applies.
If another tool requires a different authentication method, consult its documentation instead of copying a short-lived token into a field intended for something else. Avoid treating all credential fields as interchangeable.
Document the rollout decision
Write down whether the preview fits the tested workflow, what version was used, and which scripts still require work. A small team should know who will maintain the integration when the preview changes.
Do not describe token expiration as complete protection against credential theft. Refresh credentials and the device holding them still deserve the normal access and security review.
Frequently asked questions
Will existing sign-ins change automatically?
The announcement describes an opt-in preview and says behavior is unchanged if you do not opt in. Verify current documentation before a later rollout.
Why can a script fail while the CLI still works?
Inspect whether the script cached a token outside the supported refresh path. The two consumers may handle credentials differently.
What should a developer do first?
Check versions and map the credential consumers. That preparation makes an opt-in test easier to interpret and avoids surprising another person’s workflow.
Related reading: Respond to exposed API keys · Evaluate local agent access.