GitHub Desktop 3.6.10 Adds Short-Lived Tokens: Rollout Limits and Sign-In Guide

What changed​

GitHub Desktop 3.6.10 and later can use short-lived, automatically refreshing authentication tokens for eligible accounts. The security logic is simple. These tokens limit how long a leaked token stays usable. Desktop refreshes them automatically for both GitHub API requests and Git operations, so renewal stays invisible to you.

A stolen token that dies in hours is far less useful than one that works for months. A copied token can show up in a backup, a compromised profile, or a screenshot of a log file. A short lifetime shrinks the window in which that mistake can be used.

The rollout limits​

This is where the fine print counts:

• Gradual availability. The rollout is gradual on github.com and GitHub Enterprise Cloud, and does not cover GitHub Enterprise Server. Enterprise Server shops are outside this change for now.
• Existing sessions are untouched. Existing sessions remain signed in after upgrading, but existing tokens are not automatically migrated; new tokens are issued at sign-in as the rollout reaches your account.
• No published lifetime. GitHub's announcement doesn't give a Desktop token expiry or an eligibility schedule. It also doesn't describe an administrator control. Don't assume an admin can force this on across a tenant.

So an upgraded Desktop with an old session is probably still running on the old token. The new behavior arrives at the next sign-in, and only if your installation is in the rollout.

How eligibility appears to work​

GitHub's announcement doesn't say how eligibility is decided. The open-source Desktop repository gives a hint. A pull request there describes gating token acquisition on a server-side rollout decision. For production builds without preview features, Desktop checks a Central features endpoint before browser authorization, passing the installation GUID and app version. Lookup failures are logged, and sign-in continues with long-lived tokens instead of blocking.

That is a code change under review, so treat it as a clue and not as GitHub's official description. It fits the "gradual rollout" wording. It also suggests that a failed lookup means a normal sign-in, not an error. I can't tell from the evidence whether the shipped 3.6.10 behaves exactly this way.

How to sign in (Windows)​

GitHub's documentation gives these steps for Windows:

1. Open the File menu and click Options.
2. On the Accounts pane, click the appropriate Sign Into button. Use Sign Into GitHub Enterprise for Enterprise Server or Enterprise Cloud with data residency.
3. For an Enterprise account, type the URL where you access GitHub and click Continue.
4. In the "Sign in Using Your Browser" window, click Continue With Browser. Desktop opens your default browser.
5. Authenticate in the browser. If you were already signed in, follow the prompts to return to Desktop.
6. If you use two-factor authentication, enter the code from your SMS or authenticator app and click Verify.

The docs warn that signing in with a username and password inside Desktop is not supported. Authentication goes through the browser.

On macOS, the path is GitHub Desktop > Settings, then the same Accounts pane.

GitHub's page now says Desktop uses short-lived tokens when you authenticate to GitHub.com. It says this improves security by limiting how long a compromised token can be used. The announcement itself says availability is still gradual. Read the docs as the intended end state, not proof that your install has already received the feature.

Troubleshooting​

GitHub's documented fixes are mostly "sign out, sign back in":

• First step for any authentication error: sign out and back in.
• "Bad credentials": this indicates a problem with your stored credentials. Sign out and back in.
• "Empty token": Desktop can't find the access token it created in the system keychain. Sign out and sign back in.
• Logs: on Windows, use Help > Show Logs in Explorer and open the log file from the day of the error.
• AskPass errors on Windows: GitHub says to check for an Autorun value under the Command Processor registry keys, in both HKEY_CURRENT_USER\Software\Microsoft\Command Processor\ and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\, and delete it if present. It also notes that extended Unicode characters in a Windows username can cause this error. Edit the registry carefully.

Don't confuse this with GitHub CLI​

GitHub shipped a related change for its command-line tool on October 21. The two work differently:

The CLI announcement warns that scripts which capture a token once and reuse it can end up holding an expired one. Those cautions are CLI-specific. GitHub hasn't published equivalent Desktop caveats. If you use both tools, check them separately.

What it means for IT and security teams​

• Not a revocation substitute. Short-lived tokens narrow the exposure window, but they don't remove the need to respond to a compromise. GitHub's documentation says expired or revoked tokens can't be restored, and you must create a new one. It also says you can revoke all your credentials at once from account settings if you suspect a compromise or a lost or stolen device.
• Enterprise Cloud owners have controls. They can revoke SSO authorizations or delete credentials for individual users or in bulk. Deleting credentials is available for Enterprise Managed Users only.
• Existing tokens persist. Sessions that haven't signed in again keep their old tokens. A fleet-wide audit of what's stored on developer machines is still worthwhile.
• Check the version. Make sure Desktop is on 3.6.10 or later.

That last point comes from general industry practice, not from GitHub's announcement. Short-lived credentials are widely seen as better hygiene than long-lived ones. Their cost is that anything built around a static token needs rethinking.

Bottom line​

This is a modest but sensible hardening step. If you want to be among the first to get it, update Desktop to 3.6.10 or later and sign in again through the browser. GitHub hasn't said whether that will be enough on any given day. GitHub asks users to send feedback or report problems in the Desktop repository, or to contact GitHub Support.