The Horizon
GitHub CLI tokens can now expire on their own
After a week of urgent patches, this one is a quieter change. But it touches something almost every developer has on their laptop: the token gh uses to talk to GitHub.
What happened
On October 21, 2026, GitHub announced in its changelog that GitHub CLI can now use expiring, automatically refreshing OAuth tokens. It’s a public preview, and it starts with GitHub CLI v2.103.0.
Until now, gh signed you in with a long-lived token. GitHub’s own docs say it plainly: that token does not expire, and if it leaks, it grants access until you revoke it by hand.
When you opt in, gh stores two things instead: a short-lived access token and a rotating refresh token. GitHub’s docs say the access token expires within hours. When a fresh one is needed, gh swaps the refresh token for a new access token in the background. A leaked access token stops working within hours instead of lasting until someone revokes it.
What changed
- It’s opt-in. Run
gh auth login --expiringfor a single sign-in, orgh config set expiring_credentials enabledto use it for every sign-in. - Nothing changes if you do nothing. GitHub says it’s backward compatible. Existing sign-ins and manually supplied tokens keep working.
- It may not stay opt-in. The changelog says expiring credentials will become the default for new sign-ins in a future release.
- Where it works. The changelog lists github.com and ghe.com now, and GitHub Enterprise Server starting with GHES 3.23 (the CLI docs currently list only GitHub.com and GitHub Enterprise Cloud). If the server doesn’t support expiring credentials,
--expiringfalls back to a normal non-expiring token. - Checking it.
gh auth statusshows the credential, including when the current access token expires.
What to do
1. Upgrade gh to v2.103.0 or later first. The docs say expiring tokens need that version.
2. Make gh your git credential helper. For HTTPS git, the docs say gh has to be the credential helper so it can serve and refresh the rotating token. Run gh auth setup-git. GitHub also recommends git 2.46 or newer, so a caching credential helper doesn’t keep an expired token around. On older git, gh still works but prints a one-time upgrade recommendation.
3. Find scripts that copy the token once. In my view, this is the step most likely to cause problems. Any script, extension or tool that runs gh auth token once, saves the value, or pastes it into another tool will end up holding an expired token. GitHub’s advice is to call gh auth token fresh each time you need it. For an expiring credential, that command refreshes the token if needed before printing it.
4. Hold off where you need a long-lived token. GitHub says workflows that need a token to stay valid for a long time should wait before opting in.
5. Watch out when changing scopes. If you run gh auth refresh --scopes ..., pass --expiring too (or have expiring_credentials enabled). The docs say that otherwise, changing scopes can replace your expiring credential with a non-expiring one.
Why it matters for your team
I wrote this week about how secrets are the new target. A developer laptop is full of them, and the gh token is one of them. By default, that token lives until someone revokes it. With expiring tokens turned on, a copied access token expires within hours.
It’s a preview, so I wouldn’t force it on everyone tomorrow. I’d turn it on for myself, run the scripts I depend on, and see what breaks. If nothing does, that’s a cheap way to shrink one of the secrets sitting on every engineer’s machine. And since GitHub plans to make it the default for new sign-ins, finding the scripts that cache tokens now is work you’ll need to do anyway.
Sources
The Horizon
Engineering leadership for the AI era, every other week.
One honest piece every two weeks on AI in software delivery, platforms and leading teams. No spam, unsubscribe anytime.