GitHub App tokens are longer: test compatibility before changing permissions

A longer secret, not a new access grant

GitHub's October 2 announcement says the staged rollout that began on April 27, 2026 is complete. Newly minted GitHub App installation tokens default to the stateless ghs_APPID_JWT format. The ghs_ prefix remains, but GitHub describes the new tokens as about 520 characters long instead of 40. That makes old length assumptions an immediate compatibility concern. [1]

Treat the returned token as an opaque secret string: preserve it exactly without relying on decoded contents. The app JWT used to request an installation token is a separate credential from the token returned by that request. Decoding the new representation is not a substitute for GitHub's authorization checks. The generation guide still limits a token to repositories and permissions already granted to the installation or app. [1][3]

Follow the token beyond the SDK

An SDK accepting the response does not establish that every downstream component can handle it. GitHub specifically calls out fixed-length validators, bounded storage, long Authorization headers and legacy-only redaction rules. Trace the whole path from the response through caches and stores to the agent process and outbound request. [1]

• Acceptance: find exact-40-character checks and legacy-only patterns. Remove assumptions about one fixed token length; do not replace 40 with exactly 520. [1]
• Storage and injection: inspect database columns, secret stores, caches and environment-variable handling. Check for rejection, silent truncation or transformations before the agent receives the value. [1]
• Transport: inspect proxies, gateways and middleware for limits or rules affecting Authorization headers. The full value must reach the intended endpoint unchanged. [1]
• Redaction: inspect logging, traces and error reporting for rules that match only the old format. In private fixture tests, check both normal and failure paths for accidental exposure. [1]

Start with clearly labeled nonsecret synthetic fixtures in a private test harness. Cover short and longer values, more than one long length, and dots, hyphens and additional underscores allowed by GitHub's format guidance. Compare the input and output inside the harness without printing them; record only the layer and pass/fail result. Also check that fixture values are suppressed in diagnostic output. These are proposed string-handling and redaction checks—not real tokens, and not evidence that GitHub will issue or accept a credential. [2]

Hypothetical example: a successful response, a damaged token

Hypothetical, not an observed incident: an integration saves the installation token in a database field limited to 40 characters. Its SDK receives a longer token successfully, but the storage layer silently truncates it. The agent then reads the shortened value and its next request fails authentication.

In this example, increasing the app's permissions cannot restore the missing characters. Repair the storage constraint, then check exact round-trip preservation through storage, process injection and request handling without exposing the secret. Check redaction separately. The example illustrates a possible mechanism; it does not establish that a particular database, SDK or customer integration behaves this way.

If the value survives intact but the integration still fails, examine expiry, installation identity, repository scope and required permissions separately. Compatibility checks narrow the diagnosis; they do not prove every authentication or authorization failure has the same cause. [1][3]

Use the temporary override to test, not to avoid the change

GitHub's May announcement documents X-GitHub-Stateless-S2S-Token on POST /app/installations/:installation_id/access_tokens. It affects that token-creation request only: enabled requests a stateless token; disabled requests a stateful token; omitting it follows normal behavior. Values such as true, false, 1 and 0 are silently ignored, so a boolean setting does not establish that you tested the intended format. [2]

• After local handling checks, an authorized operator should validate real issuance and the existing integration with enabled and disabled while the override remains available. Keep repository scope and permissions at their intended least-privilege settings. [1][2][3]
• Test the normal no-header path as well. Record issuance, storage, transport, redaction and the intended operation separately; successful token creation alone is not an end-to-end pass.
• After both formats are validated, remove the override from production code before November 30, 2026, as GitHub instructs. The October announcement says GitHub will stop respecting it after that date. No exact cutoff hour or timezone is specified. [1]

A temporary disabled setting is not a durable rollback plan. Close the compatibility work by removing length and transport assumptions, preserving secret handling, validating the integration and eliminating dependence on the override—not by granting broader access. No token issuance or authenticated API tests were performed for this briefing.

Read the dates—and the limits—together

The generation guide retains staged-rollout and temporary-opt-in wording. Use the October 2 changelog for the completion announcement and November retirement schedule, and the guide for the token-generation and access constraints. The guide had no visible publication or update date in the material checked for this edition. [1][3]

These sources are GitHub's own documentation and announcements, not independent measurements. They do not establish an exact maximum token length or outcomes for your SDK, proxy or agent workflow. The decision here is bounded: test the token-handling path before changing access grants, and validate any remaining authorization problem on its own evidence.