Arquivo “Don't Ask Again” do Claude Code expõe senhas e chaves em 1.122 cópias públicas no GitHub
9 de Novembro de 2026

Senhas e chaves de API digitadas por desenvolvedores em comandos aprovados no Claude Code estão em repositórios públicos do GitHub, onde qualquer pessoa pode acessá-las.

Quando o usuário seleciona “Sim, e não pergunte novamente”, o assistente de programação com IA da Anthropic pode salvar o comando exatamente como foi digitado, incluindo o segredo, em um arquivo de configurações do projeto.

A empresa de segurança de software Apiiro informou ontem que encontrou pelo menos um segredo em 1.122 cópias públicas desse arquivo. A empresa não verificou se algum deles ainda funciona. Uma organização avisada pelos pesquisadores no início desta semana confirmou que sua chave estava ativa.

O arquivo é `.claude/settings.local.json`. Removê-lo do projeto não elimina o vazamento, porque versões antigas continuam no histórico do Git e em cópias derivadas do repositório. Os pesquisadores recomendam trocar primeiro todas as senhas, os tokens e as chaves que já estiveram no arquivo e só depois fazer a limpeza.

Como um segredo vai parar no arquivo

Por padrão, o Claude Code pede autorização antes de executar a maioria dos comandos do shell. Segundo a documentação de permissões, se o usuário selecionar “Sim, e não pergunte novamente”, o programa salva uma regra de autorização em `.claude/settings.local.json`, dentro do projeto. Em sessões futuras, os comandos que corresponderem à regra serão executados sem nova confirmação.

A regra se aplica apenas ao que foi apresentado na solicitação. Às vezes, ela abrange um padrão, como `npm test *`. Em outros casos, vale para um comando exato. Quando isso acontece, qualquer senha ou token digitado no comando também é salvo em texto simples.

Nos arquivos públicos, os pesquisadores encontraram comandos salvos que ainda continham os segredos. Eles também reproduziram o comportamento com os modelos mais recentes, Opus 5.5 e Fable 5.1.

O Claude Code tenta impedir que o arquivo seja incluído no Git. Na primeira vez que grava o arquivo em um repositório Git, o programa o adiciona à lista global de exclusões do usuário, segundo a documentação de configurações. Assim, o Git naquele computador ignora o arquivo em todos os repositórios.

Essa proteção vale apenas para as configurações do Git de um usuário em um computador. Ela não tem efeito sobre um arquivo que já tenha sido registrado no repositório, afirmam os pesquisadores. O Claude Code também não adiciona o arquivo ao `.gitignore` do próprio projeto, portanto a proteção não acompanha o projeto.

Em 539 dos 1.105 repositórios analisados, um registro no Git que listava o Claude como coautor mostrava que o arquivo havia sido alterado. Para os pesquisadores, isso indica que o Claude frequentemente registra o arquivo por conta própria.

O que a Apiiro encontrou

A busca da Apiiro no GitHub público encontrou 104.185 cópias do arquivo em 103.617 repositórios, segundo o relatório da pesquisa. Cerca de 1,1% delas, ou 1.122 cópias, continham pelo menos um segredo. Ao todo, eram 1.379 segredos diferentes.

Um valor foi classificado como segredo quando correspondia ao formato de uma chave conhecida ou quando uma senha ou um token aparecia ao lado do endereço de um servidor público. Um avaliador de IA também precisava concordar com a classificação. Os pesquisadores não informaram se alguém usou esses segredos.

Mais de um terço dos segredos permitia acesso direto a bancos de dados, incluindo 379 senhas de banco de dados. A lista também continha 43 credenciais de acesso SSH para servidores públicos, 42 tokens do GitHub, GitLab e npm, além de 23 chaves da AWS.

Entre os responsáveis pelos arquivos estão 63 organizações, em sua maioria empresas de software de diferentes portes. Entre os casos mais graves, os pesquisadores citam uma chave de nuvem com privilégios de administrador pertencente a uma empresa de bancos de dados e a senha de proprietário de um banco de dados de prontuários médicos.

Na segunda-feira, todos os arquivos que continham segredos ainda estavam no ramo principal de seus repositórios. Em metade desses repositórios, o arquivo estava presente havia pelo menos 217 dias.

Versões antigas do arquivo guardavam outros 734 segredos em 509 repositórios. Eles não aparecem em nenhuma cópia atual, geralmente porque o arquivo foi removido. Cópias derivadas também ampliam a exposição: 211 cópias derivadas de 74 repositórios continham os mesmos segredos dos originais.

Segredos também aparecem em 298 das 76.011 cópias do arquivo compartilhado `.claude/settings.json`, que as equipes incluem intencionalmente nos repositórios, em sua maioria dentro de regras de autorização. Somando esses casos, as versões antigas e os registros de conversas salvos pelos agentes, o total chega a 2.539 segredos em 1.994 repositórios.

Entre os 16 agentes de programação cuja documentação foi comparada pelos pesquisadores, o Claude Code foi o único confirmado como capaz de salvar, por padrão, o comando aprovado completo em um arquivo do projeto.

O que fazer

Para desenvolvedores, os pesquisadores recomendam:

- Pesquisar por `.claude/settings.local.json` e `.claude/settings.json` na organização do GitHub e verificar o histórico do Git de cada repositório, inclusive daqueles em que os arquivos já foram removidos.
- Trocar todas as senhas, os tokens e as chaves que já estiveram nesses arquivos antes de fazer a limpeza.
- Parar de rastrear o arquivo local com `git rm --cached .claude/settings.local.json` e adicioná-lo ao `.gitignore` do próprio repositório.
- Abrir o arquivo no computador, mesmo que ele nunca tenha sido registrado no Git, e remover todas as regras que contenham segredos.
- Não incluir segredos diretamente nos comandos. Em vez disso, referenciá-los como variáveis de um gerenciador de segredos, por exemplo, `$DB_URL`. Assim, a regra salva conterá o nome da variável, e não o segredo.
- Aprovar padrões, como `Bash(npm run:*)`, em vez de comandos individuais.

Mesmo as cópias que nunca chegam ao GitHub representam um risco, alertam os pesquisadores. O arquivo é um documento JSON em texto simples na pasta do projeto e também pode acabar dentro de um pacote npm, de uma imagem Docker, de um arquivo ZIP ou de uma pasta sincronizada.

Malware já foi usado para procurar segredos em computadores de desenvolvedores. Em setembro de 2025, o worm Shai-Hulud executou o scanner de segredos TruffleHog nos computadores infectados. A ferramenta sinalizou mais da metade dos arquivos como contendo segredos.

Ferramentas comuns de detecção de segredos deixam muitos desses arquivos passar. Os pesquisadores executaram o gitleaks e o TruffleHog em todas as cópias, sem usar a etapa de verificação das ferramentas. Entre os 1.122 arquivos com segredos, o gitleaks sinalizou 564 e o TruffleHog, 643. Nenhuma das ferramentas detectou 215 arquivos.

A maioria dos casos não detectados envolve senhas digitadas dentro de comandos. Os scanners procuram formatos conhecidos de chaves, mas uma senha após `PGPASSWORD=`, `sshpass -p` ou `mysql -p` parece uma palavra comum em uma linha de comando comum.

Para as equipes de segurança, os pesquisadores recomendam:

- Tratar pastas de agentes, como `.claude/`, `.cursor/`, `.gemini/` e `.specstory/`, e arquivos de memória dos agentes como locais que podem conter segredos, assim como arquivos `.env`. A recomendação vale tanto para computadores quanto para repositórios.
- Incluir esses arquivos na verificação de segredos antes do registro e na integração contínua, além de examinar o histórico do Git. As ferramentas devem detectar senhas dentro de comandos, e não apenas formatos conhecidos de chaves.
- Adicionar `.claude/settings.local.json` aos modelos de `.gitignore` da organização.
- Verificar primeiro as credenciais associadas a servidores públicos, pois são as que podem permitir acesso.

Relatos anteriores

Usuários do Claude Code já haviam relatado esse comportamento. Uma reclamação registrada em 11 de agosto de 2025 apontou que comandos aprovados com chaves de API e tokens estavam sendo armazenados exatamente como digitados em `settings.local.json`.

Um robô automatizado encerrou o relato como “não planejado” em 3 de janeiro, após 60 dias sem atividade.

Até hoje, os quatro relatos relacionados citados pelos pesquisadores foram encerrados pelo mesmo robô. O mais recente foi fechado ontem. Segundo os pesquisadores, nenhum recebeu resposta da Anthropic.

Publicidade

Anuncie no CaveiraTech e coloque sua marca na frente de milhares de profissionais de cybersecurity

Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...