Claude Code vaza senhas no GitHub: a Apiiro encontrou segredos em 1.100 arquivos de configuração

Você inicia o Claude Code, ele propõe executar um comando de shell e, para não se distrair, você clica em «Yes, and don't ask again». Prático. Mas, junto com a praticidade, você pode gravar sem perceber a senha do seu banco de dados no projeto. É exatamente isso, segundo pesquisadores da Apiiro, que acontece em milhares de repositórios.

Como o segredo vai parar no arquivo

O mecanismo é simples. Quando o usuário permite um comando para sempre, o Claude Code salva essa decisão como uma regra no arquivo local .claude/settings.local.json. Às vezes a regra é gravada como um padrão. Mas, com frequência, o comando entra no arquivo como está, com tudo o que foi escrito nele.

Imagine um exemplo típico: você pede ao agente que verifique o banco de dados, e ele executa o psql com uma string de conexão em que a senha aparece em texto claro. Ou faz um curl com um token de API no cabeçalho. Você aprova o comando «para sempre», e a linha inteira com o segredo fica no arquivo JSON.

Enquanto o arquivo permanece na sua máquina, isso é tolerável (se a máquina não for invadida). A Anthropic escreve na documentação que esse arquivo é adicionado ao .gitignore global do desenvolvedor. Mas o .gitignore global vive no seu computador, não no repositório. Se você clona o projeto em outra máquina, transforma a pasta em repositório mais tarde ou trabalha em equipe, a proteção desaparece. A Apiiro também afirma que, em muitos casos, o próprio Claude Code faz commit das alterações nesse arquivo sem a participação do usuário.

Escala e por que os scanners não salvam

Os analistas da Apiiro encontraram mais de 100.000 casos em que o arquivo local de configurações do Claude Code foi parar em um repositório público do GitHub. A maioria é inofensiva. Mas em cerca de 1.100 arquivos de 63 organizações havia segredos reais: tokens de API, senhas de bancos de dados, chaves privadas e até logins root.

Remover o arquivo do repositório não basta. Se o projeto já foi bifurcado (fork), os segredos permanecem nos forks. Ou seja, a chave deve ser considerada comprometida assim que aparecer uma única vez em um commit público.

Outro ponto desagradável: os scanners de segredos habituais não garantem proteção. Dos ~1.100 segredos encontrados, 215 passaram despercebidos tanto pelo gitleaks quanto pelo TruffleHog. O motivo é compreensível: o segredo está embutido na string do comando, e não no formato habitual KEY=value.

O histórico também não inspira confiança. O problema já havia sido relatado em bug reports em agosto de 2025. Outros relatos mencionavam que o arquivo às vezes não entrava no .gitignore e que comandos sensíveis podiam ser gravados em outro arquivo, totalmente desprotegido. Todas essas solicitações foram encerradas sem ação após 60 dias de inatividade.

No fim de semana, em uma thread no Hacker News, Boris Cherny, da equipe do Claude Code, respondeu que a equipe «está estudando o que pode ser feito». Segundo ele, esses arquivos quase nunca deveriam ir para o git, e os casos problemáticos surgem quando os arquivos foram criados e commitados manualmente. Ele recomendou o auto mode, em que classificadores decidem por conta própria quais pedidos de permissão são rotineiros. Quando outro usuário observou que, mesmo no auto mode, comandos sensíveis podem ser salvos nas configurações, Cherny reconheceu: «boa descoberta». Um scanner de segredos embutido no Claude Code é visto pela equipe como uma possibilidade futura.

O que fazer hoje

Não vale a pena esperar por um patch. Eis uma lista curta para desenvolvedores e tech leads:

• Adicione .claude/settings.local.json ao .gitignore do próprio repositório, e não apenas ao global.
• Verifique o histórico: git log --all -- .claude/settings.local.json. Se o arquivo já foi commitado alguma vez, abra-o e procure senhas e tokens.
• Reemita tudo o que encontrar. Apagar o arquivo não revoga a chave, sobretudo se houver forks.
• Não escreva segredos em comandos que você aprova «para sempre». Use variáveis de ambiente ou um gerenciador de segredos.
• Ative um scanner de segredos em pre-commit e não o trate como panaceia: os 215 casos não detectados mostram que uma única ferramenta não basta.
• Revise o próprio arquivo de configurações antes do push. É um JSON comum, e é fácil ver o que está sobrando.

Este não é o primeiro caso em que um agente de IA expõe dados sem querer. No mês passado, a Meta suspendeu a função de compartilhamento em seu agente Muse: pesquisadores descobriram que os links para materiais compartilhados eram fáceis de adivinhar.

A lição vale para quaisquer ferramentas agênticas. Tudo o que o agente memoriza para a sua conveniência se torna mais um arquivo que alguém pode publicar por acidente. Trate as configurações de agentes com o mesmo rigor que o .env.