Skip to content
Innovation & Growth

GitHub App installation tokens grow from 40 to about 520 characters

With the App installation token rollout complete, software that assumes a fixed length may now fail or leak.

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
GitHub App installation tokens grow from 40 to about 520 characters

AI-generated image for WebPulse. About our images

In brief
  • GitHub finished rolling out longer, stateless App installation tokens: about 520 characters instead of 40, with permissions and one-hour expiry unchanged.
  • Systems that assume a 40-character token, such as validation, storage, proxies or log redaction, may fail or miss the new format.
  • Teams should test with the new format and remove the temporary header from production code before November 30, 2026.

A guess that hardened into a rule

Somewhere in your software, a rule may assume a GitHub token is 40 characters long. In many codebases, nobody decided that; it was a reasonable guess that became a rule.

GitHub has now changed the token. The lesson here is that a credential's format is part of your system's interface, and format changes reach the systems that quietly depend on it.

What GitHub changed

On October 2, GitHub announced that the rollout of a new token format for GitHub Apps is complete. The rollout began on April 27, 2026. Installation tokens are the credentials a GitHub App uses to call the GitHub API.

By default, all newly minted installation tokens now use a "stateless" format. They still start with ghs_, but they are about 520 characters long instead of 40.

"Stateless" is a general term, and this is background on JWTs, not GitHub's own description. A stateless token carries its own signed data. A server can check it without looking anything up in a database.

Most of the access model is untouched. What a token is allowed to do, which repositories it covers, and how long it lasts (one hour) have not changed. The way an app requests a token has not changed either. Tokens issued before the switch keep working until they expire.

GitHub's stated reason is speed and reliability. It says the new design speeds up how tokens are created and checked, and makes its API more dependable.

40 characters
Legacy installation token length
Source: GitHub changelog (October 2, 2026)
About 520 characters
New installation token length
Source: GitHub changelog (October 2, 2026)

How the new token is built

GitHub describes the format as ghs_APPID_JWT. That is a prefix, the app's ID, and then a JWT. A JWT is a standard way to pack data into a single signed string. That packing explains the extra length.

GitHub's note does not go deeper into the internals. The practical point is simpler. The token is longer, and its shape is different.

Four places a longer token can cause trouble

GitHub asks customers to confirm that every system treats these tokens as opaque strings. An opaque string is one your code passes along without inspecting it. GitHub names four warning signs.

The first is code that insists a token be exactly 40 characters, or that matches only the old pattern. The second is storage with a hard size limit. That includes database columns, secret stores and environment variables.

The third is network equipment in the path of a request. Proxies, gateways and middleware may cut off or refuse a long Authorization header. The fourth is logging. Redaction rules that recognise only the legacy token pattern will not recognise the new one.

These failures differ in how they show up. A rejected or truncated token tends to fail loudly, because authentication stops working. A redaction rule that misses the new pattern is different. This is our inference from GitHub's list. Such a rule could let live tokens appear in logs without anyone noticing.

GitHub's note does not report any outages. It is a checklist, not an incident report.

The deadline

GitHub added a temporary request header, X-GitHub-Stateless-S2S-Token, so teams could test the new format on demand. It will be deprecated on November 30, 2026.

From that day, GitHub will ignore the header. Every eligible app will then receive stateless tokens. GitHub asks teams to remove the header from production code before then.

November 30, 2026
Header deprecation date
Source: GitHub changelog (October 2, 2026)

What to ask your team

Start with ownership. Ask who runs the GitHub Apps your company depends on, and whether they have tested with both token formats.

Then ask four specific questions. Does any code check token length or match the old pattern? Do our storage fields hold a 520-character value? Do our proxies and gateways pass long Authorization headers? Do our log filters recognise the new tokens?

Finally, ask whether the temporary header is still in production code. It should be removed before November 30.

The change is small, and GitHub has kept the parts that matter for access control the same. But a token is only a string until something depends on its shape. The cheapest time to find that dependency is before the deadline.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub.

Share this insight