Errors after GitHub App tokens grew? Migrating old validators and diagnosing authentication

What changed and which systems need checks

On October 2, 2026, GitHub announced completion of the default transition: new installation tokens use ghs_APPID_JWT, still start with ghs_, and grow from 40 to about 520 characters. Treat them as opaque strings, without fixed-length requirements or reliance on internals. Permissions, repository scope and the issuance endpoint are unchanged.

The original scope covers GitHub Enterprise Cloud and Data Residency, not GitHub Enterprise Server. Identify the actual credential type and issuance location. Personal access tokens, the app's own JWT and installation tokens are different objects; do not replace the same configuration for every GitHub authentication error.

Step 1: Distinguish issuance failures from usage failures

The official flow uses an App JWT to call POST /app/installations/{installation_id}/access_tokens, receiving an installation token and information including expires_at. Issuing the token and later using it for a business endpoint are separate stages.

Locate the failure in the program. If issuance has not succeeded, check installation ID, App JWT and that request's error response. If the token was received but form validation, storage or a later call fails, follow the handling chain. Do not store the issuance JWT where the installation token belongs, or copy either credential into logs for diagnosis.

Step 2: Find where the token first changes

Split the chain into four points: after parsing the issuance response, before storage, after reading storage and before constructing Authorization. In controlled diagnosis, compare adjacent lengths and exact contents, recording only position, length and equality externally. Compare the same token; differences between two separately issued tokens are not transport corruption.

If the value is complete before writing but shorter after reading, inspect field capacity, serialization and saving first. If unchanged but rejected before transmission, locate the rejecting validator and check fixed-length rules and old regexes. If every point matches but the gateway rejects the request, check header limits and rejection logs along that path. These symptoms narrow scope but do not independently prove a GitHub service failure.

After repair, test the same storage path with clearly labeled synthetic data covering short values, roughly 520 characters and longer values, including dots, underscores and hyphens. Confirm character-for-character readback. Do not send synthetic values to GitHub or mistake accepting them for successful authentication. This is a validation recommendation; this article did not run real-account tests.

Step 3: If the token is intact, diagnose authentication from responses

REST documentation says installation tokens expire one hour after creation and return 401 when used after expiry. Compare expires_at from issuance, check whether an old cache is still used, then inspect refresh logic. Increasing string capacity cannot fix expiry.

For Resource not accessible by integration, official troubleshooting points to insufficient permissions. Use X-Accepted-GitHub-Permissions to check endpoint requirements. 403 or 429 can also indicate rate limiting; inspect the error body and rate-limit headers. Do not immediately broaden permissions or repeat requests.

Once integrity and validity are confirmed, use read-only GET /installation/repositories in an authorized test environment to check accessible repositories. Success proves only that request works; still verify the actual business endpoint's permissions. For 404 on a private repository, check installation ownership and repository scope before assuming deletion.

When to remove the temporary format header

The temporary X-GitHub-Stateless-S2S-Token header retires on November 30, 2026 and has no effect afterward. It applies to installation-token issuance requests. Original guidance accepts enabled or disabled; values such as true and false are ignored.

Search the full header name in code and inspect configuration templates, SDK wrappers and deployment parameters for injection. Do not delete one call-site setting while a shared client keeps attaching it. After validating both formats, remove the temporary override and verify the normal issuance path. disabled is not a permanent repair.

Confirm the repair covers the real handling chain

Acceptance must answer three questions: does synthetic data survive storage and readback unchanged; does a normally issued token pass your handling chain; and does an authorized minimal business request succeed? Each addresses a different cause. A successful database expansion alone does not prove the integration is fixed.

Finally check that log redaction covers new long values. Use test strings to validate redaction rather than printing real credentials. If failure remains, hand over the stage, status code, redacted error body, length-comparison results and required permissions. The next maintainer can continue without needing the raw token.