Allow a shorter Refresh Token inactiviy lifetime and document Incident Response revocation #14967

Describe the feature or problem you’d like to solve

Thank you for adding support for expiring, automatically refreshed credentials! This is a meaningful improvement over non-expiring access tokens.

GitHub documents that the refresh token expires after six months without use. Because a successful refresh rotates it, an actively used session can persist longer than six months. If the current refresh token is stolen, an attacker may be able to exchange it for a new token pair and continue refreshing it.

I’d be comfortable trading some convenience for a shorter inactivity window. For example, with a 10-day rolling inactivity limit, my CLI would keep working after a few days away, but I’d need to sign in again after a two-week vacation.

There is also an incident-response question: if I suspect malware ran on my laptop and accessed the refreshable credential, I want to know precisely how to revoke that credential server-side, including if the attacker has already exchanged the stolen refresh token for a new pair.

Proposed solution

1. Support a shorter, server-enforced refresh-token inactivity lifetime.

Allow a user or organization to request a shorter inactivity lifetime for GitHub CLI authentication. This would let users reduce the usable window for an unused stolen refresh token while retaining automatic refresh during normal use.

A separate absolute session lifetime could also be useful, but is not essential to this request.

A client-side timeout that deletes the local credential would improve local session hygiene, but it would not shorten the validity of a refresh token already copied by an attacker. Likewise, a rolling inactivity limit would not impose an absolute session limit if an attacker keeps using the credential.

I understand this lifetime appears to be controlled by GitHub’s OAuth platform, not by gh alone. Is there an existing platform capability for this? If not, could this request be routed to the appropriate team?

2. Document the incident-response procedure for refreshable credentials.

Please document how a user or security team should respond when they suspect the GitHub CLI access token or refresh token has been stolen, for example following a malware infection on a developer laptop.

In particular:

• Does revoking GitHub CLI under Settings → Applications → Authorized OAuth Apps invalidate the current refresh token and any token pair an attacker obtained through a prior refresh?
• Is there a supported way to revoke a single device’s credential or token family, rather than the GitHub CLI authorization across all devices?
• Is there an API-supported procedure for revoking an OAuth app refresh token when its value is known? Does it work if the token has already been rotated?
• What should responders expect from gh after revocation, and what evidence or security-log events, if any, can help investigate refresh-token theft or reuse?
• Could gh auth logout or the authentication documentation point users to the server-side revocation procedure and explain its scope?

I understand that gh auth logout removes local authentication configuration and does not itself revoke tokens. Clear guidance would help responders contain an incident without mistaking local cleanup for server-side revocation.

Additional context

The GitHub CLI manual currently documents revoking the GitHub CLI OAuth app authorization and notes that this affects CLI authentication tokens across devices. More detail about rotating refresh tokens and incident response would be helpful.

A rejected refresh token could be a useful investigation signal if an attacker exchanged a stolen token before the legitimate CLI did. It would not, by itself, prove theft, and the absence of a failure would not rule out compromise.

• [GitHub OAuth: expiring access tokens](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#expiring-access-tokens)
• [GitHub CLI [gh auth logout](https://cli.github.com/manual/gh_auth_logout) manual](https://cli.github.com/manual/gh_auth_logout)
• [Refreshable OAuth token support in GitHub CLI](Refreshable (short-lived) OAuth token support #14449)
• [Earlier issue: [gh auth logout](https://github.com/cli/cli/issues/13111) and a credential retained by a Git helper](gh auth logout does not erase and/or revoke OAuth token in MacOS Keychain #13111)