Claude Code armazena em texto plano, em .claude/settings.local.json, a senha ou o token de qualquer comando que você aprovou com “Yes, and don’t ask again”. Se esse arquivo chegou a um repo público, qualquer um pode lê-lo: Apiiro Research revisou as 104 185 cópias públicas do arquivo no GitHub e encontrou um segredo real em 1122 delas, pouco mais de 1 por cento. Somando o histórico de git, os arquivos de configuração compartilhados e as transcrições de agentes, o total chega a 2539 segredos distintos em 1994 repos.
Status em 8 de novembro de 2026: Anthropic não publicou nenhuma correção nem indicou em qual versão chegaria. Os números do estudo correspondem a uma foto dos branches padrão tirada em 2 de novembro de 2026.
O estudo, de Shmulik Cohen e Matan Giladi, foi publicado em 5 de novembro de 2026. As verificações desta nota levam alguns minutos por repo e não dependem de que os números de Apiiro sejam exatos.
Claude Code armazena minhas senhas em settings.local.json?
Sim, através do aviso de aprovação. Peça ao Claude Code que revise por que o login em staging falha ou que execute uma migração, e o comando que ele propõe leva a credencial que tem sua configuração: uma string de conexão, um PGPASSWORD=, um sshpass -p ou um header bearer. Sem ela, o comando não funciona.
Claude Code pergunta antes de executar um comando de shell. Se você escolhe “Yes, and don’t ask again”, conforme a própria documentação de Anthropic, ele armazena essa aprovação como uma regra allow em .claude/settings.local.json, na raiz do seu repositório de git. A regra é o comando tal como aparece na opção que você escolheu. Quando essa opção mostra a linha de comando completa, o segredo que contém entra no arquivo junto com ela.
Apiiro afirma que é um comportamento de Claude Code, não do modelo: reproduziu com Opus 5.5 e com Fable 5.1. E quanto mais tempo você leva aprovando com “don’t ask again”, pior: um a cada dez arquivos com mais de 8 KB tinha um segredo real, em comparação com menos de um a cada 500 entre os com menos de 500 bytes.
Isso é o que Apiiro encontrou, por tipo:
| Tipo | Quantidade |
|---|---|
| Senhas de bancos de dados | 379 |
| Chaves service-role de Supabase | 122 |
| Tokens de conta de Supabase (controlam todos os projetos da conta) | 103 |
Acessos SSH, alguns como root com sshpass |
43 |
| Tokens de GitHub, GitLab e npm | 42 |
| Chaves de AWS | 23 |
| Chaves privadas | 6 |
São 1379 segredos distintos apenas nas cópias atuais de settings.local.json. Há 63 organizações afetadas, desde grupos de alunos até startups, agências e fornecedores estabelecidos. Entre os casos: uma senha de produção de Postgres no Azure, um token de produção de Square e a senha de proprietário do banco de dados de um app de registros clínicos.
Como saber se Claude Code vazou meus segredos para o GitHub?
Com quatro verificações, seguindo o procedimento de Apiiro. Substitua sua-org por sua organização ou seu usuário do GitHub.
1. O arquivo é público neste momento?
Busque o arquivo no código de sua organização no GitHub:
path:.claude/settings.local.json org:sua-org
Para uma conta pessoal, use user:seu-usuario em vez de org:. Repita a busca com path:.claude/settings.json: é o arquivo de configuração compartilhado que os times enviam propositalmente, e Apiiro encontrou segredos reais em 298 das 76 011 cópias públicas que revisou. A busca de código mostra os arquivos como estão hoje; o histórico é o passo 3.
2. Git está rastreando o arquivo neste repo?
De dentro de cada repo:
git ls-files .claude/settings.local.json
Se imprime o caminho, git está rastreando o arquivo e cada push o publica.
3. O arquivo foi enviado alguma vez para o histórico de git?
git log --all --oneline -- .claude/settings.local.json
Qualquer resultado significa que o arquivo está no histórico, mesmo que hoje não exista mais no diretório de trabalho. Para ver o que continha cada versão, adicione -p:
git log --all -p -- .claude/settings.local.json
Isso importa mais do que parece. Apiiro encontrou 734 segredos que existem apenas em versões anteriores do arquivo, em 509 repos, quase sempre porque alguém deletou o arquivo e considerou o problema resolvido. Além disso, 211 forks de 74 repos têm os mesmos segredos.
4. O que contêm suas cópias locais?
A maioria desses arquivos nunca chega ao GitHub, mas continuam sendo um armazenamento de credenciais em JSON plano dentro de seu laptop. Encontre todas as cópias:
find ~ -path '*/.claude/settings.local.json'
Busque em todos os lugares, não apenas na raiz dos repos: antes da versão 2.1.211, Claude Code armazenava o arquivo no diretório de onde você o iniciava, então pode haver cópias antigas em subdiretórios. Abra cada uma e leia sua lista allow: cada entrada é um comando que você aprovou, com tudo que você digitou nele. Dentro de Claude Code, /permissions também mostra todas as regras e de qual arquivo cada uma vem.
Encontrei um segredo: como girá-lo e tirá-lo do git com git rm --cached?
Primeiro gire, depois limpe. Deletar o arquivo não limpa o histórico de git, os forks nem os clones, então a credencial precisa ser considerada comprometida.
- Gire todas as credenciais que o arquivo teve alguma vez, incluindo as que aparecem apenas em commits antigos do passo 3.
- Pare de rastrear o arquivo e mantenha-o fora para sempre:
Depois adicionegit rm --cached .claude/settings.local.json.claude/settings.local.jsonao.gitignoredo próprio repo. - Delete todas as regras que contenham um segredo, também nos arquivos que nunca foram enviados.
- Pare de escrever segredos dentro dos comandos. Refira-se a eles como variáveis de ambiente de seu gerenciador de segredos, para que a regra armazene
$DB_URLe não a senha. - Aprove padrões, não comandos literais. Uma regra como
Bash(npm run *)cobre todos os scripts de npm e não armazena argumentos. A documentação de Anthropic aceita também a forma anteriorBash(npm run:*)como equivalente; o diálogo de permissões escreve a forma com espaço.
Claude Code já não exclui esse arquivo do git?
Tenta, e aí está justamente a brecha. Conforme a documentação de settings de Anthropic, a primeira vez que Claude Code escreve .claude/settings.local.json dentro de um repo de git, ele adiciona **/.claude/settings.local.json ao seu arquivo de exclusões global de git. Isso cobre o caso comum em sua máquina.
Não cobre:
- uma pasta que se torna repo depois que o arquivo foi criado;
- um clone em outra máquina ou no laptop de alguém do seu time;
- um arquivo que alguém já enviou;
- um arquivo que você criou manualmente: a documentação pede que você o adicione ao
.gitignore.
Como a exclusão vive em sua configuração global de git e não no .gitignore do repo, nada viaja com o projeto para protegê-lo.
As duas partes leem a evidência de forma distinta. Boris Cherny, que lidera Claude Code, escreveu no Hacker News que nesses casos os arquivos foram criados manualmente e enviados manualmente. Apiiro relata que em 539 dos 1105 repos com um segredo real que rastreou, um commit coautorado por Claude modificou o arquivo, com modelos de Sonnet 4.5 até Opus 5.5. As duas coisas podem ser parcialmente verdadeiras; em qualquer caso, a solução do seu lado é a mesma.
Por que gitleaks e TruffleHog não detectaram essas senhas?
Porque os segredos que vazam aqui quase nunca têm forma de chave. Apiiro executou gitleaks e TruffleHog sobre os 104 185 arquivos. Dos 1122 que tinham um segredo real, gitleaks marcou 564 e TruffleHog 643; 215 nenhum dos dois detectou.
Os scanners de segredos (secret scanning) buscam formatos de chave: um prefixo de provedor, uma string longa e aleatória. Uma senha depois de PGPASSWORD=, sshpass -p ou mysql -p, ou dentro de um header bearer em um curl, é uma palavra qualquer em uma linha de comando qualquer. O mesmo padrão aparece em todos os lugares onde um agente registra o que executou: transcrições, arquivos de memória, notas de handoff.
Essa brecha também importa em seu laptop. Em setembro de 2025, o worm de npm Shai-Hulud baixava TruffleHog e o executava sobre os arquivos de suas vítimas: o mesmo scanner que já detecta 643 desses arquivos.
O que as equipes de segurança deveriam mudar?
Estas são as recomendações de Apiiro para times, e valem para qualquer agente de programação, não apenas para Claude Code:
- Trate as pastas de agentes como portadoras de segredos, igual a
.env:.claude/,.cursor/,.gemini/,.specstory/e os arquivos de memória de agentes, tanto em laptops quanto em repos. - Inclua-as na verificação de segredos de pre-commit e de CI, com histórico incluído, e verifique que o scanner detecte senhas dentro de comandos (
PGPASSWORD=,sshpass -p,mysql -p, headers bearer), não apenas formatos de chave de provedor. - Adicione
.claude/settings.local.jsonaos templates de.gitignorede sua organização. - Priorize as credenciais que vêm junto a um host público: são as que dão acesso.
Apiiro também encontrou o mesmo hábito em arquivos de outros agentes: segredos reais em 120 transcrições de chat de agentes em 87 repos (exportações de .specstory, aider e Cursor) e na configuração de aprovação automática de Copilot no VS Code em 9 repos. Mas, conforme sua leitura da documentação de cada um, Claude Code é o único de 16 agentes de programação que escreve por padrão o comando aprovado completo em um arquivo do projeto.
O que Anthropic disse?
Apiiro compartilhou a pesquisa com Anthropic antes de publicá-la. Em seu comentário no Hacker News, Cherny disse que Claude Code não removeu historicamente os segredos dessas regras (secret scrubbing) e que o time está procurando como evitar isso; Apiiro adiciona que a verificação básica de segredos é uma das abordagens que Anthropic vai prototipar. Cherny também recomendou duas coisas:
- O modo auto em vez das regras de permissões. No modo auto, um classificador em segundo plano revisa as ações antes de serem executadas, então você não acumula uma lista
allow. Conforme a documentação de Anthropic,defaultModecom o valorautosó tem efeito de sua configuração de usuário (~/.claude/settings.json) ou da configuração administrada, não da do projeto nem da local. - A verificação de segredos em sua plataforma de controle de código, use o agente que usar.
No momento de publicar esta nota, Anthropic não havia lançado nenhuma correção nem indicado uma versão. Usuários reportaram esse mecanismo em issues do GitHub desde agosto de 2025 (#5544, #11982, #13106, #91270); conforme Apiiro, nenhuma recebeu resposta de Anthropic e três foram fechadas automaticamente por inatividade ou como duplicatas.
Quão confiáveis são os números de Apiiro?
Sólidos no mecanismo, que a própria documentação de Anthropic confirma, com limitações que vale conhecer:
- Apiiro vende produtos de segurança de segredos e ASPM, então tem interesse comercial no achado.
- “Segredo real” não significa validado. Nenhuma credencial foi testada nem nenhum host foi contatado. Significa um valor que corresponde a um formato de provedor ou que está junto a um host público. Apenas uma organização confirmou que sua chave estava ativa.
- A classificação combinou regras com um revisor LLM independente que trabalhou com uma rubrica escrita; um valor contou apenas quando ambos concordaram.
- A cifra do histórico é um piso, e gitleaks e TruffleHog foram executados sem seus modos de verificação.
- A comparação de 16 agentes sai de ler documentação, não de testes.
- Os números são uma foto dos branches padrão de 2 de novembro de 2026. As organizações são descritas por setor, não por nome: é responsável, mas significa que nenhum caso pode ser verificado de forma independente.
Os trabalhos anteriores apontam na mesma direção: ironPeak encontrou o arquivo em seu próprio repo em fevereiro de 2026, e Lakera encontrou credenciais em 33 desses arquivos dentro de 30 pacotes de npm em abril.
O que é Claude Code?
Claude Code é a ferramenta de programação agentica de Anthropic: funciona no terminal, em IDEs e na app desktop de Claude, lê seu repo, edita arquivos e executa comandos de shell em seu nome, pedindo aprovação a menos que uma regra ou um modo diga o contrário. Esse sistema de aprovações é o que gera settings.local.json, e é a razão pela qual um comando que o agente escreve pode levar, e deixar registrado para sempre, qualquer credencial que ele tenha visto.
E você? Qual é a primeira coisa que você verifica quando clona um repo que traz uma pasta .claude/?
- Com “Yes, and don’t ask again” quase sempre
- Escrevo minhas próprias regras com padrões
- Uso o modo auto
- Prefiro outra opção (conte qual)
Comente abaixo ou, se este artigo chegou para você por email, responda diretamente ao email: sua resposta é publicada aqui.