GitHub App ghs_ tokens are now ~520 characters: check Sume calls
GitHub's new installation tokens are about 520 characters, not 40. What breaks in a workflow that also calls Sume, and why Sume takes one credential header.
GitHub finished rolling out stateless GitHub App installation tokens on 2026-10-02: new tokens use the ghs_APPID_JWT format and are about 520 characters long instead of 40, with the same permissions, repository scoping and one-hour expiry. If the same workflow or service also calls Sume, the practical risks are a shared HTTP wrapper that puts the GitHub token in Authorization while the Sume client sends x-api-key (Sume answers 401 unauthorized when a request carries both), and secret handling code that assumed a 40-character token.
GitHub's details are from its rollout notice; Sume's header rule is from Authentication and its error codes from Errors and rate limits, read 2026-10-03.
What does GitHub say can break?
The notice tells teams to look for hard-coded 40-character length checks, fixed-size database columns, Authorization header truncation in proxies or middleware, and legacy pattern-based secret redaction. It also says the temporary X-GitHub-Stateless-S2S-Token request header, introduced on 2026-05-15, stops being respected after 2026-11-30. Existing tokens keep working until they expire.
| Item | What the notice says |
|---|---|
| Token format | ghs_APPID_JWT, about 520 characters |
| Lifetime and scope | One hour; permissions and repository scoping unchanged |
| Existing tokens | Keep working until natural expiry |
| Audit list | 40-character checks, fixed-size columns, header truncation, redaction patterns |
| Transition header | X-GitHub-Stateless-S2S-Token not respected after 2026-11-30 |
Why does the Sume call fail when I add a GitHub token?
Sume accepts Authorization: Bearer <key> or x-api-key: <key>, and a request with both is rejected with 401 unauthorized and the message Send only one API key credential. Neither header wins. So when a gateway or fetch wrapper injects Authorization for GitHub on every outgoing call, give the Sume client a separate transport, or send the Sume key only in whichever header your wrapper does not touch.
The Sume key is a different credential from the GitHub token. Do not validate it against the GitHub token's shape, and add its pattern to your secret redaction separately so it is masked in workflow logs.
Does the longer token affect Sume jobs?
No. A Sume job is created by the Sume submit, and its Idempotency-Key, status, result and webhook behavior do not depend on how your service obtained a GitHub token. If an Actions step fails on the GitHub side and is re-run, reuse the same Idempotency-Key for the Sume submit so the retry returns the original job instead of billing a second one.
Sources
Related posts
More in Developers
- Go 1.27 drains response bodies: a Sume job poll loop
Go 1.27 drains unread HTTP/1 body bytes on Close. A stdlib loop that polls GET /v1/jobs/:id/status and honors next_poll_after_seconds.
- Go webhook handler: verify the Sume sume-v1 signature
A stdlib Go verifier for x-sume-webhook-signature: HMAC-SHA256 over timestamp.raw_body, five-minute window, constant-time compare, empty secret refused.
- Goose 1.52 recipe consent before extensions: a Sume MCP recipe
Goose 1.52 asks for recipe consent before session/new spawns extensions, and caps recipe size. What to put in a recipe that uses Sume's MCP server.
- got maxRetryAfter and 429: rate_limited vs queue_full on Sume
got retries 429 and honors Retry-After up to maxRetryAfter. Sume sends 429 for rate_limited and for queue_full, which need different waits. Here is the split.
Written by Sume