Build1 publisher2 min readPublished
GitHub App tokens grow from 40 to about 520 characters, risking rejection by length checks tuned to the old format
GitHub has finished rolling out App installation tokens of roughly 520 characters, up from 40, with the ghs_ prefix unchanged. Any validator or database column sized for the old length will reject or truncate a valid credential.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Permissions, repository scope and the one-hour token lifetime are unchanged, so only the token's format has changed.
- GitHub's guidance is to handle installation tokens as opaque strings and pass them through without assumptions about their internal structure.
- A dev.to checklist on the change warns that storage layers may reject the longer tokens and intermediate layers may truncate them into a different identifier.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Once the header is deprecated on November 30, integrations lose their supported way to defer the new format, leaving code changes as the only path.
- exposure Layers that silently truncate turn a valid credential into a different string, so failures surface as authentication errors far from the column or field that caused them.
- decision Teams have to separate what GitHub states about the token, such as prefix, scope and lifetime, from what their code inferred from samples, such as length.
- cost The audit has to cover every hop the token crosses, including storage schemas and log handling, because fixing the validator alone leaves those layers unchecked.
The new token is about 13 times the old length [1]. In the old format, 36 characters followed the four-character `ghs_` prefix [2]. Any pattern pinned to exactly 36 characters after `ghs_` now rejects every new installation token. A prefix-only check still passes, since `ghs_` is unchanged [3].
Validators are the easy case because they fail where someone can see them. A dev.to checklist summarizing GitHub's October 2 update [1] lists the quieter places a length assumption lives: validation, storage, serialization, transport and diagnostic handling [8]. Somewhere, a VARCHAR(40) column sized from a sample token is about to become a design decision. According to the post, a storage layer might reject the longer value, and an intermediate layer could shorten it and leave the app holding a different identifier [7]. That truncated string would then fail authentication on a later request, several hops from the field that cut it.
GitHub handled the migration well. Permissions, repository scope and the one-hour lifetime did not change [4], so integrations face a change in the string's shape and nothing else. GitHub also offered a temporary format-selection header. It says the header will be deprecated on November 30 [5]. The post does not name the header or say what requests that still send it will get after that date.
GitHub's guidance, as the post relays it, is to treat installation tokens as opaque strings and pass them through without assumptions about their internal structure [6]. "A stricter rule can be a worse rule if it rejects valid input," the post's author wrote [9].
The test I would add is a synthetic placeholder of about 520 characters that begins with `ghs_`. Assert it is identical at each hop from the API response to the outgoing request. The post draws the right boundary around that kind of test. Local fixtures prove the code preserves a value; they do not prove a fabricated token can authenticate, and made-up credentials should never be sent to production [10].
Passing a token through untouched does not make it good. "Opaque does not mean trusted. A value can travel intact and still be expired, unauthorized, or invalid," the author wrote [11]. With the lifetime still one hour [4], expiry stays a check GitHub makes on every request.
What to watch
- GitHub's own changelog or docs naming the format-selection header and stating what requests that still send it receive after November 30.
- Whether GitHub documents a maximum installation-token length; without one, columns resized to 520 repeat the original assumption.
- Breakage reports from CI tools, proxies or secret scanners that pattern-matched the 40-character format.