Check Whether Your Code Handles the 520-Character GitHub App Installation Tokens

What changed?

According to the GitHub announcement, the phased rollout that began on April 27 has finished. Newly issued installation tokens now default to the ghs_APPID_JWT format. Stateless means GitHub can validate each token without looking up separate state on the server. The announcement explains that this makes token issuance and validation faster and improves API stability.

Here is what changed and what stayed the same. The date checked is 2026-10-12.

Source: GitHub Changelog, published 2026-10-02, checked 2026-10-12.

The prefix is the same, so the change is not visible on the surface. That is why only code that depends on length can quietly break.

What happens to tokens already issued?

The announcement says tokens issued before the change keep working until they expire. Installation tokens expire after an hour, so every time your app gets a new token, it meets the new format. The GitHub Docs also say installation tokens expire after an hour, and note that the assumption that a token is exactly 40 characters may no longer hold.

So even an app that was deployed long ago will receive the new format as time passes. That nothing went wrong today does not mean you are safe.

What ends on November 30?

The X-GitHub-Stateless-S2S-Token request header is a temporary header made so you could try the new format when needed. The announcement says this header is retired on November 30, 2026. After that day GitHub does not honor the header, and affected apps always receive stateless tokens.

The order the announcement recommends is to verify your app and workflows with both formats, then remove the header from production code. If the header stays, it has no effect after November 30, so there is no reason to delete it in a hurry, but it is better to make sure test code does not linger in production. That last sentence is a suggestion.

Where should I check in my code?

The announcement tells you to treat installation tokens as opaque strings whose contents you do not interpret. By that standard, it points you to the following four places.

1. Validation that passes only if a token is exactly 40 characters, or regular expressions tailored to the old format
2. Database columns, secret stores, and environment variables with a fixed or short length
3. Proxies, gateways, and middleware that truncate or reject long Authorization headers
4. Log masking rules that look only for the old token shape

The fourth is easy to miss. If a masking rule catches only the old shape, a new token can end up in logs in plain text. A token expires after an hour, but in the meantime it is a usable credential.

Here is a way to run the check. This order is also a suggestion.

• Search the repository for ghs_ and for length conditions such as 40 and {40}.
• Check the maximum length of the fields where you store tokens. The announcement says only about 520 characters, so do not fit to an exact value; leave a generous upper bound.
• In staging, call the API once through your proxy with a newly issued token, and check by eye that the token is masked in the logs.

What does the announcement not answer?

The announcement has no recommended field size and no regular expression for validation. It also does not say how cancellation-type actions such as revocation differ under the new format. The figure of about 520 characters is also approximate. Do not assume these things on your side; reopen the latest content of the two official pages above to confirm before you apply any changes.

In short, the token that grew to 520 characters is hard to notice because the prefix is the same. Before November 30, give four places a once-over: length validation, storage fields, proxies, and log masking.