News · DiggingBeagle record

GitHub CLI adds optional expiring OAuth tokens for automated developer sessions

GitHub CLI 2.103.0 offers opt-in short-lived access tokens with rotating refresh credentials. This reduces the reuse window for one stolen token, but does not revoke existing logins or neutralize compromised refresh tokens.

Published
Oct 21, 2026

The report

GitHub introduced an optional expiring OAuth credential flow for GitHub CLI on October 21, 2026, as a public preview. Starting with gh 2.103.0, gh auth login --expiring obtains a short-lived access token and rotating refresh credential when the server supports them. Existing logins and manually supplied tokens are not converted automatically. The GitHub changelog also documents the persistent setting gh config set expiring_credentials enabled for subsequent sign-ins.

The practical gain is a narrower reuse window after an access token leaks: GitHub says that such a token expires within hours rather than remaining valid indefinitely. There are limits to this promise. When the server does not support refreshable credentials, the CLI can fall back to an ordinary nonexpiring token. A copied refresh credential still requires protection and revocation, and scripts that store the result of gh auth token may later fail when it expires. For HTTPS Git workflows, GitHub recommends gh auth setup-git and Git 2.46 or newer to avoid stale credential caching.

This distinction matters in AI-assisted development because an agent often runs with the credentials already held by its shell or coding harness. A separate npm setup investigation describes code that could reuse a GitHub CLI token for publisher registration. Rotating access credentials would reduce the useful lifetime of an exfiltrated access token in some configurations, but it would not establish that the setup was authorized or prevent a program from reaching the token while it remains live.

Nor does expiry resolve the different failures reconstructed in the LiteLLM release compromise, where account control, build authority and credential revocation were separate links in the chain. A useful operator check therefore has four parts: determine whether a login uses expiring credentials, test refresh-token revocation, identify consumers caching extracted access tokens, and verify which unattended agents inherit each login. This is a bounded credential-lifetime change, not a new authorization policy for what an agent can do with the credential.

Research behind this