Pesquisadores da empresa de segurança Apiiro vasculharam repositórios públicos do GitHub, incluindo os arquivos de configuração local do Claude Code, o histórico do Git e os registros de conversas com agentes, e encontraram ao todo 2539 credenciais reais. Elas estão distribuídas em 1994 repositórios e envolvem 63 organizações. Entre o que vazou há senhas de bancos de dados do Azure, tokens de produção da Square, credenciais de login SSH como root e até a senha de proprietário de um banco de dados de prontuários médicos.
A origem do problema está em um botão que muita gente clica todos os dias.
O que é gravado quando se escolhe “não perguntar novamente”
Antes de executar um comando de shell, o Claude Code pede autorização. Quando o usuário escolhe “Sim, e não perguntar novamente”, essa regra é gravada no arquivo .claude/settings.local.json, dentro do diretório do projeto, e comandos do mesmo tipo deixam de exibir a janela de confirmação. O problema é que o que se grava costuma ser o texto original do comando: se ele já traz uma string de conexão de banco de dados, um token de API ou uma chave, tudo isso também fica guardado, sem alteração, nesse arquivo.
Segundo a documentação da Anthropic, ao criar o arquivo o Claude Code configura o Git para ignorá-lo. Os dados da Apiiro mostram que essa barreira falha em vários cenários: o projeto é clonado em outro computador, uma pasta comum só é inicializada como repositório Git depois, ou o arquivo é adicionado à força ao controle de versão. Em todos esses casos, o settings.local.json pode acabar sendo enviado junto.
Alguns números divulgados pela Apiiro:
- No GitHub público existem 104185 arquivos
settings.local.json, espalhados por 103617 repositórios; - Desses, 1122 (cerca de 1,1%) contêm segredos reais, o que dá 1379 depois da remoção de duplicatas;
- Nos 1105 repositórios rastreados, 539 tiveram commits assinados com a participação do Claude que modificaram esse arquivo.
Quanto maior o arquivo, maior o risco. Entre os arquivos acima de 8 KB, cerca de um em cada dez esconde uma chave verdadeira; entre os menores que 500 bytes, menos de um em cada quinhentos. As regras de autorização vão se acumulando uma a uma: quanto mais tempo o usuário clica em “não perguntar novamente”, mais coisa se junta no arquivo.
A Apiiro não testou se essas credenciais continuam válidas. Mesmo que os donos dos repositórios apaguem o arquivo, as chaves ainda podem permanecer no histórico do Git e em forks já existentes.
O problema já tinha sido relatado há muito tempo
Em 11 de agosto de 2025, um usuário já havia relatado no rastreador de problemas do Claude Code que os comandos aprovados, junto com as chaves de API e tokens que continham, eram gravados palavra por palavra no settings.local.json. O relato acabou fechado automaticamente por 60 dias sem atividade e não foi corrigido.
Mais de um ano depois, o mesmo mecanismo foi varrido de forma sistemática. Boris Cherny, responsável pelo Claude Code, respondeu no Hacker News que arquivos de configuração nunca deveriam entrar no controle de versão, que a equipe estuda formas de prevenção e considera embutir a varredura de segredos diretamente no Claude Code; até lá, recomenda que os usuários executem por conta própria uma ferramenta de varredura de chaves para fazer a limpeza. A Anthropic ainda não informou quando a correção será lançada.
Também não é a primeira vez neste mês que o Claude Code é apontado por problemas no tratamento de dados locais. No início do mês, foi relatado que ele incluía o e-mail do usuário em algumas requisições de rede; na ocasião, a correção também veio primeiro como medida de mitigação, com a versão oficial a seguir. O ponto em comum entre os dois casos é que ferramentas com agentes, para incomodar menos o usuário, gravam informações em disco ou as enviam para fora, e os desenvolvedores têm dificuldade de perceber o que de fato é registrado.
O que os desenvolvedores podem fazer agora
Quem já usou o Claude Code pode começar procurando, nos repositórios locais e remotos, os arquivos .claude/settings.local.json e .claude/settings.json, para ver se há comandos com credenciais em texto puro. As chaves confirmadas como expostas devem ser revogadas e reemitidas; apagar o arquivo não basta.
Um hábito mais seguro é não colocar chaves em parâmetros de linha de comando e, em vez disso, referenciá-las por variáveis de ambiente ou ferramentas de gerenciamento de segredos. Além disso, convém ativar no repositório a varredura de segredos do GitHub ou uma verificação equivalente antes do commit, para que esse tipo de arquivo seja barrado antes do push.
Fontes: ITHome, relatório de pesquisa da Apiiro, CocoLoop, Ars Technica, The Hacker News; foram conferidos o número de arquivos de configuração, a proporção de arquivos com chaves, o total de credenciais e o número de organizações afetadas.