Why it mattersAny integration that validates a token's length as 40, truncates long Authorization headers, or caps a database column at 40 characters will start failing in production.
A GitHub App whose code was written when installation tokens were 40 characters long now has a dependency it never saw before: the exact byte length of a string it treats as opaque.
GitHub announced on October 2 that the staged rollout of its stateless installation token format, which started on April 27, 2026, is complete. All newly minted GitHub App installation tokens are now issued in the ghs_APPID_JWT format, which GitHub says makes token issuance and validation faster and improves API reliability. Permissions, repository scoping, the one-hour expiration, and the installation access token REST API endpoint are unchanged. The tokens still start with ghs_.
What changed and what will break
The change is a length jump: tokens are now about 520 characters instead of 40. Everything else about how a token is used is identical. Tokens minted before the change continue to work until they expire.
GitHub asks every team that handles installation tokens to treat them as opaque strings and lists four things to look for:
- Validation that requires tokens to be exactly 40 characters or regex patterns written for the legacy format.
- Database columns, secret stores, or environment variables with a fixed or small maximum length.
- Proxies, gateways, or middleware that truncate or reject long Authorization headers.
- Logging and secret redaction rules that only match the legacy token pattern.
An API gateway with a header size cap of 8 KB would survive, but a regex that reads ^ghs_[a-zA-Z0-9]{36}$ will not match a stateless token, and a varchar(40) column in a secrets table will truncate it on write. These are the kinds of silent failures a team will not notice until an app makes a call with a saved token that was already corrupted.
The November 30 deadline
GitHub added a temporary X-GitHub-Stateless-S2S-Token request header back when the rollout started, so apps could validate the new format on demand. That header is being deprecated on November 30, 2026. After that date, GitHub will no longer respect the header, and every eligible app will always receive stateless tokens, with no way to opt back into the old format for one call.
The practical move: use the header once between now and the deadline to force a stateless token in a controlled test, confirm the whole chain accepts it, then remove the header from production. GitHub says any system that already treats installation tokens as opaque strings has nothing to do.
For a team maintaining a GitHub App, this is the kind of change that reads as nothing in the changelog and causes an outage three weeks later. The six-month staged rollout has finished, so the testing opportunity is now and the clock stops on November 30.
Source
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.
