Clicar em “Sim, não perguntar de novo” parece inofensivo. Só que, segundo uma pesquisa publicada em 5 de novembro de 2026, esse gesto no Claude Code ajudou a deixar senhas no GitHub à vista de qualquer pessoa.
A empresa de segurança Apiiro encontrou 2.539 segredos reais em 1.994 repositórios públicos. A lista inclui senhas de banco de dados, chaves de nuvem, tokens de API e acessos SSH de administrador.
Neste artigo, você entende como isso acontece, como checar se os seus projetos foram afetados e o que fazer para evitar o problema daqui em diante.
Como as senhas vão parar no GitHub
Quando você pede ao Claude Code para consultar um banco ou chamar uma API, o comando proposto pode levar junto a senha que estava no seu arquivo de configuração. Antes de rodar, a ferramenta pede autorização.
Se você escolher “Yes, and don’t ask again”, o comando exato é salvo como regra de permissão em .claude/settings.local.json, dentro da pasta do projeto. A senha vai junto, em texto puro.
A própria ferramenta tenta manter esse arquivo fora do Git, adicionando-o à lista global de arquivos ignorados do desenvolvedor. A Apiiro aponta que isso não cobre tudo: uma pasta que vira repositório depois, um clone em outra máquina ou um arquivo que já tinha sido enviado.
Em 539 dos 1.105 repositórios rastreados com um segredo real, um commit com coautoria do Claude alterou o arquivo. A pesquisa também diz ter reproduzido o comportamento com modelos recentes, porque ele vem da ferramenta, e não do modelo.
.claude/ como você trata o arquivo .env: ela pode guardar segredos, mesmo que você nunca tenha digitado uma senha ali de propósito.
O que a pesquisa encontrou
A Apiiro analisou 104.185 cópias públicas do arquivo. Delas, 1.122 traziam um segredo real, cerca de 1,1%. Parece pouco, mas a proporção cresce com o uso: um em cada dez arquivos acima de 8 KB tinha um segredo.
Mais de um terço dava acesso direto a bancos de dados. Foram 379 senhas de banco e 122 chaves de serviço do Supabase, ferramenta muito popular entre quem cria apps com IA. Outros 103 eram tokens de conta do Supabase, que controlam todos os projetos da conta.
O problema não para nesse arquivo. Agentes de código também deixam segredos em outros lugares que costumam ser enviados ao GitHub:
| Onde | Arquivos analisados | Com segredo real |
|---|---|---|
| .claude/settings.json (compartilhado) | 76.011 | 298 arquivos |
| Transcrições de chat de agentes | 2.523 | 120 arquivos em 87 repositórios |
| Arquivos de memória, como MEMORY.md | 1.200 | 9 repositórios |
| Notas de passagem e de implantação | 2.095 | 33 arquivos |
| Autoaprovação do Copilot no VS Code | 173 | 9 repositórios |
Um detalhe preocupa mais: os detectores de segredos deixam muita coisa passar. O gitleaks sinalizou 564 dos 1.122 arquivos, e o TruffleHog, 643. Outros 215 não foram apontados por nenhum dos dois. Uma senha depois de PGPASSWORD= parece só uma palavra comum na linha de comando.
Vale registrar um limite do estudo: “segredo real” significa que a credencial tem o formato de um provedor ou aponta para um servidor público. A Apiiro diz não ter testado nenhuma, então não dá para afirmar que todas ainda funcionam. A empresa também vende produtos de segurança para esse mercado.
Como verificar se os seus projetos foram afetados
Se você usa o Claude Code, siga esta ordem. Os comandos só consultam informações e não alteram nada:
Dentro do projeto, rode
git ls-files .claude. Se settings.local.json aparecer, ele está sendo versionado. No GitHub, procure o caminho do arquivo nos repositórios da sua conta.Rode
git log --all --oneline -- .claude/settings.local.json. Se houver resultado, o arquivo já passou pelo repositório. Apagar agora não limpa o histórico, as cópias nem os forks.Abra o arquivo na sua máquina e leia a seção de regras permitidas. Procure senhas, tokens, chaves e endereços de conexão. Faça isso mesmo que o arquivo nunca tenha ido para o GitHub.
Achou algo? Gere novas senhas e chaves antes de qualquer limpeza. Segundo a Apiiro, deve-se trocar toda credencial que o arquivo já guardou, porque remover o arquivo não desfaz a exposição.
Rode
git rm --cached .claude/settings.local.json e adicione esse caminho ao .gitignore do próprio repositório. Depois, apague da lista toda regra que contenha um segredo.
Como evitar que isso se repita
A mudança principal é de hábito: pare de colocar segredos em comandos. As recomendações do estudo são simples de aplicar:
- Use variáveis: faça o comando citar
$DB_URL, e não o valor. A regra salva guarda só o nome da variável. - Aprove padrões: autorize algo como
Bash(npm run:*)em vez de um comando literal com todos os dados. - Leia antes de aprovar: depois da décima pergunta, é fácil clicar sem olhar. Uma senha pode ser só uma palavra em uma linha longa.
- Inclua as pastas de agentes na varredura:
.claude/,.cursor/,.gemini/e.specstory/merecem o mesmo cuidado do.env.
Mesmo sem GitHub, há risco. A Apiiro lembra que programas maliciosos já vasculham computadores de desenvolvedores atrás de credenciais, e cita o caso do worm Shai-Hulud, de 2025. Para mais cuidados, veja as 5 falhas de segurança que a IA deixa no seu código.
O que a Anthropic disse
Segundo a Apiiro, a Anthropic recebeu a pesquisa antes da publicação. Depois, Boris Cherny, que lidera o Claude Code, escreveu no Hacker News que a empresa está avaliando como prevenir o problema e que vai testar uma varredura básica de segredos.
O texto da Apiiro não cita uma correção já disponível. Por isso, vale fazer as verificações agora. A empresa também diz ter avisado as organizações mais expostas nos dias 2 e 3 de novembro.
Perguntas frequentes
Isso é uma falha do modelo de IA?
Segundo a Apiiro, não. É um comportamento da ferramenta, que grava o comando aprovado. Por isso, ele foi reproduzido também com modelos recentes da Anthropic.
Só o Claude Code tem esse problema?
A pesquisa comparou 16 agentes pela documentação e diz que o Claude Code é o único confirmado que grava por padrão o comando completo em um arquivo do projeto. Mas segredos também apareceram em arquivos de outras ferramentas.
Meu repositório é privado. Estou seguro?
O risco é menor, mas existe. O arquivo pode sair em um pacote publicado, em uma imagem Docker ou em uma pasta sincronizada. E continua legível para qualquer programa malicioso na sua máquina.
Apagar o arquivo resolve?
Não. O histórico do Git guarda as versões antigas: o estudo achou 734 segredos em versões anteriores do arquivo. O passo mais importante é trocar as credenciais.
Conclusão
O caso das senhas no GitHub mostra que o risco de um agente de código também está nos arquivos que ele cria sem que você perceba. Cinco minutos de verificação podem evitar um banco de dados aberto.
Quer conhecer outro caso recente? Leia sobre a extensão do Claude Code com backdoor e como se proteger.