O botão, o ficheiro e o comando
A empresa de segurança aplicacional Apiiro publicou a 6 de novembro um estudo que encontrou 2.539 segredos reais em 1.994 repositórios públicos do GitHub, quase todos escritos ali pelo próprio ficheiro de permissões de um agente de programação.
O mecanismo é banal. O Claude Code pergunta antes de executar um comando de consola. Se se escolher “Sim, e não voltes a perguntar”, guarda uma regra de permissão em .claude/settings.local.json, dentro da pasta do projeto. Quando a regra aprovada é um comando literal e não um padrão, tudo o que foi escrito nesse comando — uma palavra-passe de base de dados, um token, um acesso SSH — fica guardado com ele, em texto simples, num ficheiro que vive ao lado do código.
A Apiiro percorreu o GitHub público entre 1 e 3 de novembro e encontrou 104.185 cópias desse ficheiro em 103.617 repositórios. Destas, 1.122, cerca de 1,1%, continham um segredo real: 1.379 valores distintos no total, dos quais 636 correspondiam ao formato de chave de um fornecedor conhecido e 743 eram palavras-passe ou tokens junto a um servidor público. Mais de um terço abre diretamente uma base de dados, incluindo 379 palavras-passe de bases de dados e 122 chaves de papel de serviço da Supabase, além de 43 acessos SSH a servidores públicos, 42 tokens do GitHub, GitLab e npm e 23 chaves da AWS.
Porque é que os ficheiros são públicos
O Claude Code tenta manter o ficheiro local: quando o cria dentro de um repositório, acrescenta-o às exclusões globais de git do programador. Isso cobre o caso comum e mais nada. Não cobre uma pasta que se torna repositório depois, um clone numa segunda máquina, ou um ficheiro que alguém já tenha submetido, e a regra nunca entra no .gitignore do próprio repositório, pelo que nenhuma proteção viaja com o projeto.
A Apiiro nota ainda que muitas vezes é o próprio agente que submete o ficheiro: em 539 dos 1.105 repositórios com um segredo real que conseguiu rastrear, um commit coassinado pelo Claude alterou-o. As instruções de commit do Claude Code dizem ao modelo para não submeter .env nem credentials.json; o seu próprio ficheiro de configuração não consta dessa lista. De 16 agentes de programação cuja documentação a Apiiro comparou, diz que o Claude Code é o único em que se confirma a escrita, por omissão, do comando aprovado completo num ficheiro do projeto.
A exposição não é breve. Todos os ficheiros afetados continuavam no ramo principal do seu repositório quando a Apiiro verificou, e no caso mediano estavam lá há 217 dias. Apagá-lo não fecha a brecha: versões anteriores do ficheiro guardam mais 734 segredos em 509 repositórios que não aparecem em nenhuma cópia atual, e 211 bifurcações de 74 repositórios carregam os mesmos valores.
O que os scanners falham, e o que diz a Anthropic
Os scanners genéricos apanharam cerca de metade. Passados sobre os 104.185 ficheiros, o gitleaks assinalou 564 dos 1.122 com um segredo real e o TruffleHog 643; 215 não foram assinalados por nenhum. A diferença está nas palavras-passe escritas dentro de comandos — depois de PGPASSWORD=, sshpass -p ou mysql -p —, que parecem palavras comuns e não formatos de chave.
A Apiiro diz ter avisado cada organização afetada a 2 e 3 de novembro, e a Anthropic pelo canal de divulgação que a empresa indica. Nota também que utilizadores reportam o mecanismo em incidências do GitHub do Claude Code desde agosto de 2025, que nenhuma teve resposta e que três foram fechadas automaticamente por inatividade ou duplicação.
O responsável pelo Claude Code na Anthropic, Boris Cherny, respondeu no Hacker News a 7 de novembro. “Historicamente o Claude Code não fez limpeza de segredos (há muitas boas ferramentas para isso), mas estamos a ver o que podemos fazer para o impedir”, escreveu, citando “garantir que o modo automático apanha isto, incorporar uma análise básica de segredos” entre as abordagens que a equipa iria prototipar “antes de lançarmos algo”. Disse ainda que o Claude Code coloca o ficheiro no gitignore quando o cria, pelo que, a seu ver, as cópias expostas foram criadas à mão e submetidas.
Os limites do próprio estudo estão declarados: nenhuma credencial foi usada ou testada, e “segredo real” significa um valor que corresponde ao formato de um fornecedor ou aponta para um servidor público, não um que se saiba funcionar. Uma empresa avisada confirmou que a sua chave estava ativa. O conselho que daí decorre é pouco vistoso: rodar tudo o que o ficheiro alguma vez conteve, deixar de o rastrear e aprovar padrões em vez de comandos literais.
