Tokens de instalação de GitHub App agora são JWTs de 520 caracteres

O GitHub terminou de mudar todos os tokens de instalação de GitHub App recém-criados para um novo formato "stateless" (sem estado), disse a empresa em seu changelog em 2 de outubro de 2026. Os tokens continuam começando com ghs_, mas agora têm cerca de 520 caracteres em vez de 40. Qualquer código que presumia o tamanho antigo, como um padrão de validação ou uma coluna de banco de dados, agora pode rejeitar ou cortar um token que funciona.

O que mudou

Um token de instalação é a senha de curta duração que um GitHub App usa para agir nos repositórios em que está instalado. O GitHub começou uma implantação em etapas do novo formato em 27 de abril de 2026. O changelog de 2 de outubro diz que essa implantação está concluída, então o novo formato agora é o padrão.

O novo token é um JWT, sigla de JSON Web Token: uma string assinada que carrega informações dentro dela. Segundo o changelog de maio do GitHub, dá para distinguir os dois formatos contando os pontos. Um token stateless contém dois pontos, enquanto o antigo token opaco não contém nenhum.

	Formato antigo	Formato novo
Prefixo	ghs_	ghs_
Tamanho	40 caracteres, fixo	cerca de 520 caracteres, pode variar
Pontos no token	0	2
Validade	1 hora	1 hora, sem mudança

Permissões, escopo de repositórios e a expiração de uma hora continuam iguais, diz o GitHub. Só o formato da string mudou.

O que o token carrega

O projeto Kingfisher, da MongoDB, um scanner que procura segredos vazados, descreveu o formato em uma issue aberta em 26 de abril. Ele escreve o padrão como ghs_APPID_JWT. A parte JWT guarda detalhes como a instalação de destino e o app, além de dados básicos de validação, segundo a issue.

Esse JWT é assinado pelo emissor interno do próprio GitHub. A issue do Kingfisher diz que apps clientes não devem tentar validá-lo. Para o seu código, o token deve continuar sendo uma string opaca: algo que você guarda e envia, nunca interpreta.

O Kingfisher também apontou que a sua própria regra de detecção para esses tokens precisaria de uma atualização quando a implantação terminasse. Scanners de segredos que buscam o antigo formato de 40 caracteres são um dos lugares onde essa mudança aparece primeiro.

O header de override e o seu prazo

Em maio, o GitHub adicionou um header temporário, X-GitHub-Stateless-S2S-Token, à requisição que cria um token de instalação. Enviar enabled retorna um token no formato novo. Enviar disabled retorna um token no formato antigo, mesmo para apps que já foram migrados. Omitir o header segue o padrão.

Essa saída de emergência está se fechando. O changelog de 2 de outubro diz que o header será descontinuado em 30 de novembro de 2026. Depois dessa data, as equipes que fixaram o formato antigo para ganhar tempo vão perder essa opção.

O changelog de maio do GitHub lista o GitHub Enterprise Cloud e as suas regiões de residência de dados como cobertos. Ele também cita o GITHUB_TOKEN do Actions, o token que os workflows usam, ao lado dos tokens de App server-to-server.

O que isso significa para desenvolvedores

Procure no seu código qualquer coisa que trate esses tokens como de tamanho fixo. A orientação do GitHub cita quatro pontos problemáticos: verificações de tamanho, limites de colunas de banco de dados, truncamento de headers e padrões de log. Cada um pode falhar em silêncio. Uma coluna que guarda 40 ou 255 caracteres vai cortar o token, e a chamada à API então vai falhar com o que parece um erro de autenticação.

Corrija os padrões de validação em seguida. Um padrão como ghs_[A-Za-z0-9]{36} rejeita o novo token, porque o token é mais longo e contém pontos. O changelog de maio do GitHub sugere ghs_[A-Za-z0-9.\-_]{36,}, que aceita os dois formatos. Confira o seu próprio padrão com uma amostra inventada de cada formato em um testador de regex, nunca com um token real.

Garanta que o armazenamento comporte pelo menos 520 caracteres, diz o GitHub. Isso inclui caches, cofres de segredos e variáveis de ambiente com limite de tamanho. Se você oculta segredos nos logs, teste se a ocultação ainda pega o token mais longo. Do contrário, parte de uma credencial real pode acabar em texto puro.

Se você definiu o header de override como disabled no primeiro semestre, tem até 30 de novembro para removê-lo. Teste primeiro com enabled, depois apague o header.