Tokens GitHub App maiores: reveja a regra dos 40 caracteres
Se apenas tokens novos falham, examine o caminho da string antes de ampliar permissões. A emissão funcionar não prova que banco ou proxy preservou o valor.
Em 2 de outubro de 2026, GitHub anunciou o fim do rollout stateless dos tokens de instalação de Apps. ghs_APPID_JWT mantém ghs_, mas cresce de 40 para cerca de 520 caracteres; não é regra para todos os tokens pessoais.
Separe formato e acesso
Permissões, escopo dos repositórios, expiração de uma hora e endpoint REST não mudam. Mais acesso não corrige truncamento; investigue emissão e uso separadamente.
O header temporário X-GitHub-Stateless-S2S-Token será descontinuado em 30 de novembro de 2026. Valide ambos os formatos e remova antes, registrando responsável e prazo.
Preserve a string completa
Trate o token como string opaca. Procure validadores de 40 caracteres, colunas pequenas, limites de cofres e rejeição de headers Authorization longos.
Teste primeiro com valores sintéticos e registre apenas comprimentos e resultados. Não transforme 520 em novo limite rígido; confira as restrições documentadas de todo o caminho.
Revise também os logs de erro
Mascaramento feito para o formato antigo pode deixar parte do novo visível. Use dados sintéticos para inspecionar rejeições, novas tentativas e exceções.
A orientação GitHub inclui privilégio mínimo, mascaramento e revisão de logs. Sugerimos envolver responsáveis por armazenamento e logs; autenticação bem-sucedida não basta.
Teste pequeno e registre o prazo
A pergunta prática é se os sistemas preservam a string de ponta a ponta. É uma inferência do comunicado, não uma suposta opinião dominante da comunidade.
Fora de produção, conclua testes sintéticos, chamada de privilégio mínimo e revisão de logs antes de ampliar. Essa ordem é nossa proposta. Registre ponto de falha, responsável e prazo do header.