GitHub changes App installation token format: from 40 to ~520 characters, breakage risk for CI/CD pipelines

GitHub announced on April 24, 2026 a significant change to the App installation token format that begins phased rollout as early as April 27, 2026. The change has the potential to break integrations and CI/CD pipelines that have hard-coded the current 40-character token length — which includes a large number of custom scripts and database schemas in production.

What exactly is the new format?

The old format looks like this: ghs_ + 36 alphanumeric characters = 40 characters total. The new format is structured as a JWT (JSON Web Token) with the prefix ghs_APPID_JWT and a total length of approximately 520 characters, with the note that it will “vary based on the data stored within it” — in other words, the length is not fixed but depends on the content. JWT is a standardized format (RFC 7519) for secure JSON data transmission, cryptographically signed so that integrity can be verified without a round-trip to the server. According to GitHub’s announcement, the JWT “contains details about the token such as the target installation, the application, and basic validation details”.

Who is affected and when?

GitHub divides the rollout into two phases. Phase 1 (April 27 – mid-May 2026) covers GitHub Actions GITHUB_TOKEN and so-called featured integrations such as Dependabot, Slack and Teams integrations. Phase 2 (mid-May – end of June 2026) covers all App installation tokens, including users of GitHub Enterprise Cloud and environments with Data Residency requirements (EU, Australia, other regions). In practice — every organization using GitHub Apps for authentication in CI/CD pipelines should prepare immediately.

What MUST developers do?

GitHub is very explicit about three key actions:

1. Database schema: “Any database columns for access tokens can fit at least a 520 character string” — verify that all columns storing tokens support at least 520 characters. A typical VARCHAR(40) or VARCHAR(64) will no longer work.
2. Regex checks: Remove all regex patterns like ghs_[A-Za-z0-9]{36} that were used to validate token format. The new format contains underscores and characters that do not match the old pattern.
3. Length checks: “Your apps do not take a dependency on access tokens being a certain length” — any logic that assumes a fixed length of 40 characters must be revised.

Why is GitHub doing this?

Security and performance motivation. The JWT format enables stateless validation — the server does not need to perform a DB lookup on every call to verify token validity; it can verify the signature locally. GitHub states that the change “improves token issuance performance under increased load” and delivers “higher reliability at scale”. In other words — GitHub is preparing its authentication infrastructure for the growth in call volume coming from the explosion of AI agents and automated bot integrations.

What if I ignore the change?

Applications that assume the old length will start producing errors upon first encountering a new token. The most common symptoms: DB INSERT failures (truncated string), regex validation rejections, Authorization header parser errors. It is advisable to proactively audit all repositories and custom Actions in the coming days before the rollout catches up with your organization.