GitHub App installation tokens are now stateless and about 520 characters long: test the opt-in header out by 30 November 2026

GitHub App installation tokens are now stateless and about 520 characters long: test the opt-in header out by 30 November 2026

2 October 2026: On 2 October 2026 GitHub announced that the staged rollout of a new token format for GitHub App installation tokens, which began on 27 April 2026, is complete. By default, every newly issued installation token now uses a stateless format. It still begins with ghs_, but it is about 520 characters long where the old one was 40. Integrations that assumed the old length can break without any change on your side.

Not yet independently verified. Single source (GitHub changelog). No independent report read at 2026-10-03. We will update this when it can be confirmed, and remove this note.

What changed

GitHub says the new format is built on a signed token with the app identifier embedded, which makes issuing and validating tokens faster and improves the reliability of the API. Several things stay the same: token permissions, repository scoping, the one-hour lifetime, and the REST endpoint used to create an installation access token. Tokens minted before the change continue to work until they expire.

A temporary request header, X-GitHub-Stateless-S2S-Token, was introduced earlier so teams could try the new format on demand. GitHub will deprecate it on 30 November 2026. After that date it will no longer respect the header, and all eligible apps always receive stateless tokens.

Who is affected

Anyone who builds or runs GitHub Apps, and anyone who operates systems that handle their tokens: continuous-integration platforms, deployment tools, bots, internal developer portals and secret managers. GitHub specifically points to four places where the longer token causes trouble:

• validation code or patterns that expect exactly 40 characters, or only the legacy pattern;
• database columns, secret-store entries 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 recognise the legacy token pattern, which would let the new tokens appear in logs unmasked.

Hosted tools from other vendors that store GitHub tokens on your behalf are in scope too. If a vendor's integration fails after today, a length limit is a likely cause.

What to do

1. List every system that stores, forwards or logs GitHub App installation tokens and check each for a length limit near 40 characters.
2. Treat tokens as opaque strings: remove length and format assumptions from validation code.
3. Update redaction and secret-scanning rules to match the longer ghs_ format so that tokens do not leak into logs.
4. Check reverse proxies and API gateways for header-size limits and raise them if needed.
5. If you used the temporary header to test, remove it from production code before 30 November 2026.
6. Ask vendors whose products hold your GitHub App tokens to confirm support for the new format in writing, and diarise 30 November as the date to re-check.

Sources

• GitHub Changelog: Stateless GitHub App installation tokens rolled out - 2 October 2026