Developer Security
An Auto-Refreshing GitHub Login Can Still Leave a Script Holding an Expired Token
A script that reads a token once can outlive the value it captured. GitHub's October 21 preview introduces expiring, automatically refreshing CLI credentials, but that refresh does not update a copied string in another process. The safe migration question is where each consumer obtains its next credential.
Citation-ready: GitHub CLI v2.103.0 adds opt-in expiring OAuth credentials in public preview; scripts that cache a token can still fail after that token expires.
Evidence boundary: GitHub public-preview documentation only. No sign-in, credential export, helper change or account migration was performed for this article. Server-version support and opt-in status remain explicit.
What happened and why it matters
Credential refresh works at a particular integration boundary; an external process holding a copied access token needs its own supported way to obtain a current value.
Primary evidence
Primary reference: GitHub CLI expiring OAuth public-preview notice. Kaleido Field checked the event date and the article's attributed facts against this source.
| Source date | October 21, 2026 |
|---|---|
| Checked by Kaleido Field | October 26, 2026, CST |
| Source function | developer security -> token lifecycle and reliable automation |
Refreshing the login does not refresh every copy
GitHub says the CLI stores a short-lived access token and a rotating refresh token when a user opts in. Existing sign-ins are unchanged unless opted in, and older unsupported servers can fall back to nonexpiring behavior.
Inventory scheduled jobs and extensions before changing authentication. Identify which process requests the token and whether another process saves it for later. A successful interactive command does not prove a background job will obtain a fresh value after the original one expires.
Verify the path rather than printing the secret
The notice recommends the CLI credential helper for HTTPS Git operations and warns that copied tokens can become stale. The preview begins with CLI v2.103.0 and has server-version qualifications.
An authorized rollout should record versions, expiry behavior and the outcome of a delayed test without exposing token values in logs. Keep rollback conditions explicit. The enterprise App analysis covers a different credential choice for administrative automation.
Evidence boundary
GitHub public-preview documentation only. No sign-in, credential export, helper change or account migration was performed for this article. Server-version support and opt-in status remain explicit.
FAQ
Does opting in change every existing sign-in?
No. The release describes opt-in behavior and preserves existing sign-ins unless they are explicitly changed.