GitHub Completes Stateless App Installation Token Rollout, Growing Tokens From 40 to About 520 Characters

Overview

GitHub has finished moving GitHub App installation tokens to a new stateless format. According to the GitHub Changelog, the staged rollout, which began on April 27, 2026, is complete, and by default all newly minted installation tokens now use the ghs_APPID_JWT format. GitHub says the format makes token issuance and validation faster and improves the reliability of the GitHub API.

What Changed

• Length. Installation tokens still start with the ghs_ prefix, but per the same changelog entry they are now about 520 characters long instead of 40.
• Unchanged behavior. GitHub says token permissions, repository scoping, the one-hour expiration and the installation access token REST API endpoint are unchanged, and tokens minted before the change continue to work until they expire, per the GitHub Changelog.
• Format. In its May 15 announcement, GitHub described a stateless token as a ghs_-prefixed JWT that contains two dots, whereas a stateful token is a short opaque string with no dots.

The Opt-Out Header and Its Deadline

During the rollout, GitHub offered a temporary request header. According to the May 15 changelog entry, setting X-GitHub-Stateless-S2S-Token on a POST /app/installations/:installation_id/access_tokens request overrides the server-side rollout decision for that single request. A value of enabled returns a stateless token and disabled returns a stateful one.

The October 2 entry says the header will be deprecated on November 30, 2026. After that date, GitHub will no longer respect it, and all eligible apps will always receive stateless tokens. GitHub advises removing the header from production code before that date.

What Integrators Should Check

GitHub’s documentation warns that an application that expects installation tokens to be exactly 40 characters long may not handle the new format correctly. The October changelog asks organizations to confirm that every system handling installation tokens treats them as opaque strings, and lists as examples validation that requires exactly 40 characters or patterns written for the legacy format, and logging and secret-redaction rules that only match the legacy token pattern.

The May 15 entry also lists database columns for token storage and header settings that should accept at least 520 characters, and gives a recommended regular expression for matching both formats: ghs_[A-Za-z0-9\.\-_]{36,}, according to the GitHub Changelog.

Scope

Per the May 15 entry, the change applies to GitHub Enterprise Cloud and Data Residency environments, while GitHub Enterprise Server is not impacted. It also says upcoming rollouts would apply the new format only to GitHub App installation server-to-server tokens, including the Actions GITHUB_TOKEN.

What We Don’t Know

The sources reviewed are first-party GitHub documents; no independent reporting on integration failures was located. GitHub’s October entry does not quantify how many apps were affected or report any incidents. The May entry said GitHub would share more details on planned format changes for user-to-server tokens used in Copilot code review flows, and the October entry does not address them, so the timing of that change remains unconfirmed here.