Segredos vazados no settings.local.json do Claude Code: audite regras 'Don't Ask Again' e rotacione chaves

A GitGuardian encontrou 5,343 segredos que ainda funcionavam no momento da detecção, todos em cópias públicas de um único arquivo de projeto do Claude Code, o .claude/settings.local.json. As credenciais vão parar ali porque o Claude Code pede permissão antes de executar um comando de shell, e uma das respostas que ele oferece, "Yes, and don't ask again" ("Sim, e não perguntar novamente"), grava o comando aprovado nesse arquivo. A GitGuardian e uma segunda equipe de pesquisa, a Apiiro, publicaram cada uma contagens que mostram grandes quantidades de credenciais, de senhas de banco de dados a tokens de API, em cópias públicas desse único arquivo.

Se você é gerente de engenharia, líder de plataforma ou DevSecOps, ou CTO de uma equipe de desenvolvedores que usa o Claude Code, este guia oferece uma sequência prática: encontrar cada cópia exposta, neutralizar as credenciais, limpar os repositórios e artefatos e, por fim, fechar os caminhos que o arquivo usa para escapar.

O que "Yes, and don't ask again" realmente grava em disco

Quando um desenvolvedor escolhe "Yes, and don't ask again" para um comando Bash, duas coisas acontecem. Segundo a GitGuardian, o Claude Code executa o comando e grava uma regra de permissão (allow rule) em .claude/settings.local.json na pasta do projeto, e a regra é a própria string do comando, com chave de API e tudo. Pense nos comandos que os desenvolvedores aprovam em um dia de trabalho normal: uma chamada PGPASSWORD=... psql para um banco de dados de staging, um login sshpass -p '...' ssh, uma sessão mysql -p... ou um curl com um bearer token. Aprove qualquer um deles de forma permanente e a credencial é salva junto com o comando.

A documentação da Anthropic confirma isso. A documentação de configurações diz que escolher "Yes, and don't ask again" para um comando Bash salva essa aprovação como uma regra de permissão no settings.local.json. A documentação de permissões acrescenta que as aprovações permanentes vão para .claude/settings.local.json na raiz do repositório git, resolvido por meio das worktrees até o checkout principal.

A Anthropic tem um relato público desse comportamento desde agosto de 2025.

O tamanho da exposição: duas contagens de pesquisa, lado a lado

A Apiiro publicou sua pesquisa em 6 de novembro de 2026. Ela relatou que 1,122 de 104,185 cópias públicas do arquivo no GitHub continham pelo menos um segredo. Esses arquivos guardavam 1,379 segredos distintos, incluindo 379 senhas de banco de dados, 43 logins SSH de servidores públicos e 23 chaves da AWS. Quando a Apiiro ampliou a busca para versões antigas do arquivo, para o arquivo de configurações compartilhado que as equipes fazem commit de propósito e para transcrições salvas de chats com agentes, a contagem chegou a 2,539 segredos em 1,994 repositórios.

A varredura própria da GitGuardian encontrou 31,088 segredos distintos em .claude/settings.local.json no GitHub público, em 23,276 repositórios, sendo que 5,343 deles ainda funcionavam no momento da detecção. Os segredos válidos apenas no settings.local.json incluem 1,955 strings de conexão Postgres distintas, 292 senhas SSH e 941 chaves de API do Google. Nossa leitura dessa combinação é que boa parte do risco ativo está em bancos de dados e servidores, e as contas de API de terceiros são só uma parte do quadro.

Os dois estudos diferem em escopo, janela de tempo e método de detecção, então leia-os como medições separadas de um mesmo problema. Somá-los resultaria em contagem dupla, e nenhum deles deve ser tratado como correção do outro.

A GitGuardian também acompanhou a tendência. Os vazamentos mensais no settings.local.json atingiram o pico de 12,535 ocorrências em abril de 2026 e caíram para 959 em outubro. A GitGuardian diz que ainda não sabe o que mudou.

Por que a proteção nativa e seus scanners não detectam o problema

O Claude Code vem com uma proteção. Segundo a documentação de configurações, na primeira vez que ele grava o arquivo em um repositório git que ainda não o ignora, ele adiciona **/.claude/settings.local.json ao arquivo global de exclusões do git do usuário. Essa entrada fica na máquina do próprio desenvolvedor e não entra no .gitignore do projeto. A nota de pesquisa da Cloud Security Alliance explica por que isso não basta: uma exclusão global protege um desenvolvedor em uma estação de trabalho, e ela não acompanha o repositório até o clone de um colega, um runner de CI, um notebook novo, uma imagem de contêiner ou um tarball do npm.

A detecção é a segunda lacuna. No conjunto de dados da Apiiro, o gitleaks sinalizou 564 dos 1,122 arquivos com vazamento e o TruffleHog sinalizou 643, mas nenhuma das ferramentas sinalizou 215 deles, principalmente porque os segredos eram senhas embutidas na sintaxe de comandos, como PGPASSWORD=, sshpass -p ou mysql -p. Os números da GitGuardian apontam na mesma direção. Detectores genéricos (senhas, strings de alta entropia, JWTs, bearer tokens, pares de usuário e senha) produziram 63% de todas as ocorrências no settings.local.json: 44,755 de 71,525.

Além do GitHub: imagens Docker, pacotes npm e CLAUDE.md

O arquivo não fica só no git. A GitGuardian examinou imagens públicas do Docker Hub e encontrou 613 segredos distintos em arquivos de configuração do Claude Code, 99 deles válidos no momento da detecção, distribuídos por 543 repositórios de imagens e 7,625 tags.

Essas contagens de tags mostram como um único erro se multiplica. Um token de API válido da Cloudflare apareceu em 559 tags de uma única imagem, e uma senha de banco de dados apareceu em 643 tags em sete repositórios de imagens. Segundo a GitGuardian, apagar o arquivo do repositório não resolve nada para imagens que já foram publicadas.

Os registros de pacotes carregam o mesmo risco. Uma pesquisa da Check Point, citada na nota da CSA, encontrou 428 pacotes npm públicos que incluíam um arquivo .claude/settings.local.json, e 33 desses arquivos, em 30 pacotes, continham credenciais. A auditoria também precisa ir além dos arquivos de configuração. A GitGuardian descobriu que arquivos CLAUDE.md continham 6,155 segredos distintos, 2,537 deles válidos, a maior taxa de validade entre todos os arquivos que ela examinou.

O playbook Encontrar, Neutralizar, Limpar, Fechar

A ordem das etapas importa mais do que qualquer comando isolado. Encontrar abrange as Etapas 1 a 3, Neutralizar é a Etapa 4, Limpar abrange as Etapas 5 a 7, e Fechar é o trabalho de prevenção da seção seguinte a esta. Neutralizar vem antes de Limpar porque a limpeza não consegue recolher cópias que já existem em outros lugares: forks e imagens já publicadas mantêm o segredo por mais minuciosa que seja a reescrita do histórico, e só a rotação torna essas cópias inúteis.

Etapa 1 (Encontrar): Inventário

Liste todos os repositórios, registros de contêineres e pacotes publicados que sua organização controla, incluindo repositórios arquivados, espelhos internos e os forks pessoais que as pessoas usam para trabalhar. O que ficar fora da lista não será limpo.

Etapa 2 (Encontrar): Pesquise as árvores atuais e todo o histórico do git

Procure por .claude/settings.local.json, .claude/settings.json, CLAUDE.md e quaisquer transcrições de agentes exportadas. Pesquise todo o histórico, além do branch atual, porque a contagem maior da Apiiro veio de versões antigas de arquivos, arquivos de configuração compartilhados e transcrições. Uma busca filtrada por caminho na sua plataforma de hospedagem de código serve como uma primeira passada rápida. Para uma passada por repositório, sugerimos um comando parecido com este, que também procura arquivos .jsonl caso as transcrições da sua equipe tenham sido salvas nesse formato:

git log --all --name-only --pretty=format: | grep -E '[.]claude/|CLAUDE[.]md|[.]jsonl$' | sort -u

Trate essa saída como ponto de partida para as transcrições. As que foram salvas fora do git, ou com outros nomes de arquivo, precisam de uma busca separada.

Etapa 3 (Encontrar): Leia os arquivos, não apenas a saída do scanner

Esses arquivos são curtos o suficiente para que alguém os abra e leia as regras de permissão diretamente. Para uma busca em todo o histórico de repositórios grandes, sugerimos passar as revisões para o git grep uma de cada vez, em vez de todas de uma vez:

git rev-list --all | while read -r rev; do
  git grep -nE 'PGPASSWORD=|sshpass -p|mysql[^|]*[[:space:]]-p[^[:space:]]|Authorization: Bearer' "$rev" -- '*.json' '*.jsonl' '*.md'
done

As equipes podem achar um loop como este lento em históricos longos, e buscas por padrões desse tipo tendem a gerar falsos positivos. Trate cada ocorrência como uma credencial real até que uma pessoa confirme que não é.

Etapa 4 (Neutralizar): Rotacione ou revogue cada credencial primeiro

Segundo o GitHub, se os dados sensíveis forem um segredo, o primeiro passo é revogá-lo ou rotacioná-lo. Na prática, isso significa rotacionar a senha do banco de dados, emitir um novo token e substituir a credencial SSH, e depois verificar que cada valor antigo deixou de funcionar. Até confirmar que uma credencial está inativa, presuma que ela está ativa.

Etapa 5 (Limpar): Pare de rastrear as configurações locais e revise as configurações compartilhadas

Pare de rastrear o arquivo local e adicione a regra de exclusão ao próprio .gitignore do projeto, para que ela chegue a cada clone e runner de CI:

git rm --cached .claude/settings.local.json
echo '.claude/settings.local.json' >> .gitignore
git add .gitignore
git commit -m "Stop tracking Claude Code local settings"

Também sugerimos pedir a cada desenvolvedor que remova da sua cópia local do arquivo todas as regras que contenham credenciais.

Etapa 6 (Limpar): Reescreva o histórico, reconstrua imagens, republique pacotes

Depois de confirmada a rotação, reescreva o histórico onde isso ajudar, reconstrua as imagens afetadas e republique versões limpas dos pacotes, aceitando que alguma exposição vai permanecer. O GitHub alerta que, se o commit que introduziu os dados sensíveis existir em algum fork, ele continuará acessível ali. Sugerimos tratar versões antigas de pacotes como ainda acessíveis, a menos que você tenha confirmado o contrário.

Etapa 7 (Limpar): Registre o que você fez

Mantenha um registro curto do incidente. Para cada credencial encontrada, anote o responsável, a data da rotação e qualquer exposição residual que você não consiga remover, como forks, imagens já baixadas e versões antigas de pacotes. O registro transforma uma limpeza pontual em algo que auditores e equipes futuras podem verificar, e vale a pena incorporar esse registro de incidente ao seu runbook de incidentes com agentes para que o próximo vazamento siga um caminho que as pessoas já conhecem.

Checklist para entregar às equipes

• [ ] Encontrar: repositórios, registros e pacotes listados, incluindo repositórios arquivados e forks
• [ ] Encontrar: árvores e todo o histórico pesquisados em busca de arquivos de configuração, CLAUDE.md e arquivos .jsonl; transcrições fora do git pesquisadas separadamente
• [ ] Encontrar: arquivos lidos por uma pessoa, além de verificações personalizadas para PGPASSWORD=, sshpass -p e mysql -p
• [ ] Neutralizar: cada credencial rotacionada ou revogada, com o valor antigo confirmado como inativo
• [ ] Limpar: settings.local.json fora do rastreamento e no .gitignore do projeto; settings.json sem credenciais e revisado em pull requests
• [ ] Limpar: histórico reescrito onde for útil, imagens reconstruídas, pacotes republicados
• [ ] Limpar: registro do incidente concluído, com forks e versões antigas de pacotes listados como exposição residual
• [ ] Fechar: os controles de prevenção abaixo implementados

Fechar: mantendo segredos fora dos comandos aprovados

A regra de permissão é a string literal do comando, então a prevenção se resume a manter as credenciais fora dessa string.

• Use variáveis em vez de valores. Passe as credenciais por variáveis de ambiente ou por um gerenciador de segredos, para que o comando aprovado contenha o nome de uma variável em vez do segredo. Defina a variável fora do comando aprovado, na sessão de shell ou em um wrapper do gerenciador de segredos, porque um VAR=secret cmd inline ainda grava o segredo na regra de permissão. Antes: aprovar PGPASSWORD=s3cret psql -h staging-db -U app salva a senha. Depois: com PGPASSWORD já definida no ambiente, aprovar psql -h staging-db -U app não salva nenhum segredo. Para um padrão mais robusto, veja como um proxy de credenciais mantém chaves de API longe de agentes de IA.
• Leia antes de clicar. Antes de conceder uma aprovação permanente, sugerimos ler o comando exato e, se ele contiver uma credencial, aprová-lo apenas uma vez. O mesmo hábito de ler antes de aprovar vale também para aprovações remotas de agentes.
• Faça commit da regra de exclusão e revise o arquivo. Coloque .claude/settings.local.json no .gitignore de cada projeto em vez de depender de exclusões globais e, de tempos em tempos, remova regras de que os desenvolvedores não precisam mais.
• Bloqueie no pre-commit e na CI. Rejeite commits que adicionem o arquivo de configurações locais e sinalize sintaxes de comando com credenciais que os scanners padrão podem deixar passar.
• Feche os caminhos de empacotamento. Adicione os caminhos .claude/ ao .dockerignore e use uma lista explícita de arquivos permitidos ou uma lista de exclusão nos pacotes npm, para que o arquivo não vá junto.

O que a Anthropic disse até agora

O relatório de bug original tem um histórico irregular. A nota da CSA registra que ele foi marcado como "not planned" ("não planejado") em 3 de janeiro de 2026, sem nenhuma resposta de mantenedor exibida na página. O relatório foi aberto em agosto de 2025, e as fontes analisadas aqui não explicam o intervalo entre essa abertura e a data de fechamento em janeiro.

Desde então, a Anthropic respondeu publicamente, embora ainda não tenha lançado uma correção. Boris Cherny, líder do Claude Code, disse ao iTnews: "Historicamente, o Claude Code não fez limpeza de segredos (existem muitas boas ferramentas para isso), mas estamos analisando o que podemos fazer para evitar isso." No Hacker News, Cherny listou possíveis abordagens, incluindo garantir que o modo automático detecte isso e incorporar uma varredura básica de segredos. Ele disse que a equipe faria protótipos de algumas delas para entender os trade-offs antes de lançar algo.

Ressalvas e limites destas orientações

• A validade é um retrato do momento. Os 5,343 segredos válidos da GitGuardian refletem o momento da detecção. Alguns podem ter sido rotacionados desde então, e outros não.
• A queda não tem explicação. A GitGuardian não sabe por que as ocorrências mensais caíram depois de abril de 2026, então a queda não prova que o problema foi resolvido.
• Repositórios privados estão fora do escopo. A pesquisa abrange repositórios, imagens e pacotes públicos. Repositórios privados têm a mesma exposição sempre que os arquivos são compartilhados ou incorporados a artefatos.
• O comportamento pode mudar. Consulte novamente a documentação oficial de configurações e permissões do Claude Code antes de finalizar a política interna.
• Os comandos são pontos de partida. Os trechos de busca acima são sugestões para adaptar e testar no seu próprio ambiente, e não ferramentas de detecção completas.