GitHub Begins Rollout of New 520-Character Installation Token Format Today (April 2026)

GitHub on April 24, 2026 announced a staged rollout that will replace the long-standing 40-character ghs_ installation token with a new stateless ghs_APPID_JWT format roughly 520 characters long. The change starts today, April 27, 2026, on Actions-issued GITHUB_TOKEN and first-party integrations such as Dependabot, Slack, and Teams, and rolls out to all GitHub App installation tokens between mid-May and late June.

What Happened

In a changelog post titled "Notice about upcoming new format for GitHub App installation tokens," the GitHub Apps team said it is "now supporting a new, stateless token format for GitHub App installation tokens that improves token issuance performance under increased load and helps us deliver higher reliability at scale." The change applies to GitHub Enterprise Cloud and Data Residency environments. GitHub Enterprise Server is not affected.

The new format keeps the familiar ghs_ prefix that GitHub introduced in its 2021 token-format overhaul — the one that lets secret-scanning tools instantly identify a leaked GitHub token. What changes is everything after the prefix: instead of a random 36-character body, the token will encode the application ID and a GitHub-signed JSON Web Token containing the target installation, the application, and basic validation details.

Key Details

• New format: ghs_APPID_JWT — approximately 520 characters, varies based on the data stored within the token.
• Old format still works: existing 40-character ghs_ tokens continue to work until they expire (installation tokens have a 1-hour TTL).
• Stage 1 — April 27 to mid-May 2026: rollout to Actions-issued GITHUB_TOKEN and first-party integrations (Dependabot, Slack, Microsoft Teams).
• Stage 2 — mid-May to late June 2026: rollout to all GitHub App installation tokens issued via POST /app/installations/{id}/access_tokens.
• JWT is opaque: the embedded JWT is signed by an internal GitHub issuer and "cannot nor should not be validated by a client app," GitHub says.
• User-to-server tokens not yet in scope: the format change for tokens used in Copilot code-review flows is "not in scope yet" but GitHub will share more details in coming weeks.

What Developers and Users Are Saying

The reaction inside GitHub Community discussions and Hacker News threads has been mostly positive but with a clear undertone of "you broke my regex." Many integrations — including older Action runners, custom secret-scanning rules, and SaaS connectors that proxy GitHub tokens — hard-code an assumption that ghs_ tokens are exactly 40 characters. GitHub's own guidance says "there are no regexes in your codebase such as ghs_[A-Za-z0-9]{36} that validate a token. These may not match the new tokens." Database administrators are also being warned to widen access-token columns to fit at least 520 characters.

Maintainers of popular community libraries like actions/create-github-app-token are already auditing length assumptions, and several CI vendors confirmed on X that they are pre-emptively widening their token columns and dropping any client-side ghs_ regexes.

What This Means for Developers

If you build or operate any GitHub App, Action, or integration that stores, validates, or pattern-matches on installation tokens, you have a small but non-trivial migration to do before the late-June broad rollout:

• Treat tokens as opaque strings. Do not validate against fixed lengths or regex patterns like ghs_[A-Za-z0-9]{36}.
• Widen storage columns. Database fields, Redis keys, environment-variable size limits, and HTTP header sizes must accommodate at least 520 characters.
• Audit log redaction. If you scrub tokens from logs by length, swap to prefix-based redaction (ghs_*).
• Test in staging now. GitHub says it will publish guidance on testing the new tokens locally and will introduce a brownout period to surface integrations that still depend on old format assumptions.
• Opt-out (Actions only): if the change breaks an existing Actions workflow during the early rollout, GitHub Support can temporarily opt your repo out — but only until the broad enablement.

What's Next

GitHub plans to follow the installation-token migration with a similar update to user-to-server tokens — the credentials that power Copilot code-review and other interactive flows. No date has been published yet. The company also said a brownout period will run before broad enablement so that any remaining length-assumption bugs surface in non-production windows. Maintainers of GitHub Apps should subscribe to the GitHub Changelog RSS feed for the rollout schedule and consult the official authentication docs at docs.github.com.

Sources

• GitHub Changelog — Notice about upcoming new format for GitHub App installation tokens — primary announcement from the GitHub Apps team.
• @GHchangelog on X — official GitHub Changelog post summarising the rollout.
• GitHub Docs — Generating an installation access token for a GitHub App — reference for how installation tokens are issued.
• GitHub Docs — Generating a JSON Web Token (JWT) for a GitHub App — JWT signing requirements for the apps that mint these tokens.
• GitHub Blog (2021) — Behind GitHub's new authentication token formats — historical context on the original ghs_ prefix design.
• Releasebot — GitHub Release Notes (April 2026) — third-party tracker confirming the April 27 staged rollout.