- GitHub put expiring, auto-refreshing login tokens for its command-line tool into public preview in v2.103.0. They are opt-in, and GitHub says a leaked token becomes unusable within hours.
- The risk shifts to scripts and tools that copy a token once and reuse it. Those can end up holding an expired token.
- Teams should find where tokens are stored, check git and server versions, and hold off for workflows that need long-lived tokens.
A leaked password is a problem. A leaked password that never expires is a permanent one.
Most credential leaks are small. A token ends up in a log, a pasted snippet or a shared laptop. The damage depends on how long that token keeps working. If it works for years, a small slip stays dangerous long after anyone remembers it.
GitHub has now put that lifetime on the table. In a changelog post on October 21, GitHub announced a public preview of expiring, automatically refreshing OAuth credentials in its command-line tool, GitHub CLI. GitHub says that with the option on, a leaked access token "becomes unusable within hours instead of lasting indefinitely."
The idea is that a credential should be a lease, not a deed. This points to a shift in how identity security is thought about. The question moves from whether a token can be protected to how long it stays useful if protection fails. That is the publication's argument, drawn from one tool's preview.
How the new login works
GitHub CLI, called gh, lets developers and automated jobs sign in to GitHub from a terminal. Today the token it stores does not expire.
With the new option, gh stores two things. One is a short-lived access token, which is the credential actually presented to GitHub. The other is a rotating refresh token, which gh uses to obtain a fresh access token when the old one lapses. GitHub says gh does this in the background, so the user stays signed in without doing anything.
Starting with v2.103.0, a user opts in by running gh auth login with the new --expiring flag. A single setting, gh config set expiring_credentials enabled, turns it on for every future sign-in. The command gh auth status shows when the current access token expires.
Where it can break
The change has a cost. GitHub cautions that a tool which copies a token one time and keeps using that copy may stop working. Because the token is short-lived, a script or extension that saves the output of gh auth token is holding a copy that will go stale. So is anything that pastes the token into another tool.
That is the quiet failure mode. A job that ran for months can stop one day, with no change to the job itself.
GitHub's guidance is specific. Tools that sit outside gh should call gh auth token each time they need a credential. That command renews the token when required instead of returning a saved value. For workflows that need a token to stay valid for a long time, GitHub's advice is to leave them out of the opt-in for now.
Git over HTTPS calls for one more recommended step. GitHub strongly recommends running gh auth setup-git, which makes gh the credential helper for git. Then gh hands git a current credential and renews it as needed.
GitHub also urges teams to use git 2.46 or later. From that version, gh can flag short-lived credentials so git does not keep them past their expiry. With an older git, gh keeps working but shows a single upgrade suggestion.
Scope and limits
The feature can be used today on github.com and ghe.com. On GitHub Enterprise Server, support begins with release 3.23. Older server releases do not honor the request, so users get the same non-expiring token as now. GitHub says the same happens with any server that cannot issue refreshable credentials.
Nothing changes for anyone who does not opt in. People who already signed in, or who supply a token by hand, see no difference. GitHub also says it plans to make expiring credentials the default for new sign-ins in a future release. That is a stated plan, not a date.
The announcement does not say how long an access token lasts beyond "hours." It does not say whether other kinds of GitHub tokens get the same treatment. Treat this as one tool's preview, not a platform-wide change.
What to ask your team
First, where do your scripts and automations store a GitHub token? Any that run gh auth token once and save the output are the ones likely to fail.
Second, which workflows truly need a long-lived credential? GitHub says to leave those out of the opt-in. Knowing that list now makes the future default less disruptive.
Third, do developers use git 2.46 or newer? Do any self-hosted servers run a GHES version older than 3.23? Those servers fall back to non-expiring tokens, so the protection will not apply there.
A credential that expires turns a forgotten leak into a short-lived one. The price is that every tool holding a copy must learn to ask again.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub.
