GitHub completes stateless app installation token rollout

GitHub says its staged rollout of stateless GitHub App installation tokens is complete, changing the default format for newly minted installation tokens after a rollout that began on April 27, 2026. The company says eligible tokens now use the stateless ghs_APPID_JWT format by default, a change intended to make token issuance and validation faster and to improve GitHub API reliability.

The practical impact is small for integrations that already treat access tokens as opaque secrets, but it can be disruptive for systems that made assumptions about token length or structure. GitHub says the tokens still start with ghs_, while the new tokens are about 520 characters long instead of about 40. Permissions, repository scoping, the one hour expiration, and the REST API endpoint for installation access tokens are unchanged. Tokens created before the change continue to work until they expire.

What teams should check

For security and platform teams, the useful part of the announcement is the checklist. GitHub advises app operators to confirm that validators do not require a 40 character token, that database columns and secret stores can hold the longer value, and that proxies or middleware do not truncate or reject longer authorization headers. Logging and redaction rules also need a second look, because secret masking that only matches the older pattern can leave new tokens exposed in logs.

The temporary X-GitHub-Stateless-S2S-Token header is also on a clock. GitHub says it will stop respecting that header after November 30, 2026, so teams that used it to test the new format should remove it from production code before then. That date turns the rollout from a background platform change into a maintenance deadline for GitHub App owners.

CyberOGZ view

The safest decision rule is simple: anything handling installation tokens should store and forward them as arbitrary secret strings, not as values with a known length. That principle is already common security practice, but this rollout gives teams a concrete reason to audit older glue code, dashboards, and gateway policies. The highest risk is not that GitHub changed permissions. GitHub says those stay the same. The risk is quieter: a token rejected by a fixed length rule, clipped by infrastructure, or missed by a redaction pattern during an incident.

Because GitHub Apps often sit inside release, deployment, and security automation, failures can show up far from the code that caused them. A short preflight across storage fields, reverse proxies, CI secrets, and log filters is cheaper than discovering the assumption when an app starts failing API calls or leaking credentials during troubleshooting.

Sources

• github.blog

Cover photo by Tima Miroshnichenko on Pexels, used under the Pexels License.