Claude Code: Don’t Ask Again grava senha no Git

Em 7 de novembro de 2026 o The Hacker News relatou a pesquisa da Apiiro: 1.122 cópias públicas do arquivo .claude/settings.local.json no GitHub guardam pelo menos um segredo — 1.379 segredos distintos no total, entre senhas de banco, logins SSH, tokens de GitHub, GitLab e npm, e chaves AWS. A Apiiro não testou se as credenciais ainda funcionavam; uma empresa avisada pelos pesquisadores confirmou que a chave dela estava ativa. A matéria aponta o write-up original em apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again (HTTP 200 nesta noite) e a Cyber Security News publicou nota no mesmo tema (cybersecuritynews.com/claude-codes-yes-and-dont-ask-again/, indisponível ao coletor desta rodada).

O mecanismo não é um exploit remoto nem um plugin trojanizado. Quando o Claude Code pede permissão para rodar um comando e a pessoa escolhe Yes, and don’t ask again, a ferramenta grava uma regra allow com o comando exato — senha inclusa, em texto puro — dentro do projeto. Isso é outro canal do que já cobrimos na extensão Claude Code no Cursor com backdoor SSH e no Dispatch que vira RCE a partir de uma extensão no browser: aqui o vazamento começa num clique de permissão e termina num arquivo de projeto que o Git publica.

Como o segredo entra no arquivo

Por padrão o Claude Code pergunta antes de executar a maior parte dos comandos de shell. A documentação de permissões e a de arquivos de configuração descrevem o que acontece no clique permanente: a aprovação vira uma regra allow em .claude/settings.local.json, normalmente na raiz do repositório Git. Na sessão seguinte, um comando que case com essa regra roda sem prompt.

A regra cobre só o que o prompt ofereceu. Às vezes é um padrão, como npm test *. Às vezes é o comando literal inteiro. Quando o agente montou algo como conectar no banco com a senha na linha — ou exportou PGPASSWORD, usou sshpass -p ou mysql -p... — esse literal é o que fica salvo. Os pesquisadores reproduziram o comportamento com os modelos atuais citados na matéria (Opus 5.5 e Fable 5.1) e acharam, nos arquivos públicos, comandos ainda com o segredo dentro.

O arquivo é JSON simples na pasta do projeto. Mesmo que nunca chegue ao GitHub, ele pode viajar num pacote npm, numa imagem Docker, num zip ou numa pasta sincronizada. Em setembro de 2025 o worm Shai-Hulud, segundo a mesma reportagem, rodou o scanner TruffleHog em máquinas infectadas e o scanner sinalizou mais da metade desses arquivos como contendo segredo.

O que a proteção do Claude Code cobre — e o que não cobre

A documentação oficial diz que o Claude Code tenta manter o arquivo fora do Git. Na primeira vez em que o escreve num repositório que ainda não o ignora, ele adiciona **/.claude/settings.local.json ao arquivo global de excludes do usuário: o caminho de core.excludesFile, ou $XDG_CONFIG_HOME/git/ignore, ou ~/.config/git/ignore quando essa variável não está definida. O Git daquela conta, naquele computador, passa a ignorar o arquivo em todos os repositórios.

Três ressalvas da própria pesquisa, alinhadas à documentação:

• Essa proteção mora nas configurações do Git de um usuário em uma máquina. Ela não viaja com o projeto.
• O Claude Code não adiciona o arquivo ao .gitignore do repositório. Um colega, um CI ou um clone em outro computador não herda o exclude.
• Arquivo que já foi commitado continua no histórico — e nos forks — mesmo depois de apagado da árvore atual. Tirar do disco não desfaz o vazamento.

A documentação de gitignore deixa isso explícito: padrões de ignore valem para arquivos ainda não rastreados. O que já está no índice precisa sair com git rm --cached. Quem criou o settings.local.json à mão, antes de o Claude Code escrevê-lo, também precisa ignorá-lo por conta própria.

Há um detalhe extra nos números: em 539 dos 1.105 repositórios que os pesquisadores rastrearam, um commit listando o Claude como coautor tinha alterado o arquivo. A leitura deles é que o próprio agente muitas vezes commita o arquivo que deveria ficar de fora.

O que a Apiiro encontrou de fato

A varredura pública, conforme o The Hacker News citando o write-up, achou 104.185 cópias do arquivo em 103.617 repositórios. Cerca de 1,1% — as 1.122 cópias — tinham pelo menos um segredo, somando 1.379 segredos distintos. Contou-se como segredo um valor no formato conhecido de chave, ou uma senha/token ao lado do endereço de um servidor público, com um revisor de IA concordando. Os pesquisadores não afirmam que alguém já tenha usado essas credenciais.

Mais de um terço dos segredos abre um banco diretamente, inclusive 379 senhas de banco. Também aparecem 43 logins SSH para servidores públicos, 42 tokens de GitHub, GitLab e npm, e 23 chaves AWS. Entre os donos dos arquivos há 63 organizações, em sua maioria empresas de software de vários portes. Os casos mais graves citados incluem a chave de nuvem com nível administrativo de um fornecedor de banco e a senha de dono de um banco de prontuários médicos.

Na data em que a matéria descreve o recorte (“as of Monday”), todo arquivo com segredo ainda estava no branch padrão do repositório; em metade desses repositórios ele estava lá havia pelo menos 217 dias. Versões antigas do arquivo, já apagadas da árvore atual, guardavam mais 734 segredos em 509 repositórios. Forks espalham o mesmo material: 211 forks de 74 repositórios repetiam os segredos dos originais. O arquivo compartilhado .claude/settings.json — este os times commitam de propósito — também tinha segredos em 298 de 76.011 cópias, quase sempre dentro de regras allow. Somando arquivo local, arquivo compartilhado, histórico e logs de conversa do agente, o total reportado é 2.539 segredos em 1.994 repositórios.

Dos 16 agentes de código cuja documentação os pesquisadores compararam, o Claude Code foi o único confirmado a gravar o comando aprovado por completo, num arquivo do projeto, por padrão.

Por que o scanner do repositório deixa passar

Isso lembra o problema de senha que vaza no log e o de segredo em GitHub Actions: o valor está onde a ferramenta de detecção não espera. Os pesquisadores rodaram gitleaks e TruffleHog em todas as cópias, sem o passo de verificação das ferramentas. Das 1.122 com segredo, o gitleaks sinalizou 564 e o TruffleHog 643; nenhum dos dois sinalizou 215. A maior parte das falhas é senha digitada dentro do comando. Scanner procura formato conhecido de chave; uma senha depois de PGPASSWORD=, sshpass -p ou mysql -p parece palavra comum numa linha comum.

Como checar agora, sem clonar repositório alheio

Comece pelo que está na sua máquina e na sua organização. Não é preciso varrer o GitHub inteiro nem clonar projeto de terceiro.

# Ache o arquivo local (rode na pasta do seu time ou no HOME)
find . -name 'settings.local.json' -path '*/.claude/*' 2>/dev/null

# Confira se o Git já rastreia o arquivo neste repositório
git ls-files -- '.claude/settings.local.json' '.claude/settings.json'

# Histórico, mesmo se o arquivo já saiu da árvore atual
git log --all --full-history -- '.claude/settings.local.json' '.claude/settings.json'

# O exclude global desta máquina conhece o padrão?
git config --global --get core.excludesFile
# Se vazio, o padrão costuma ser ~/.config/git/ignore
grep -n 'settings.local.json' ~/.config/git/ignore 2>/dev/null
cat "$(git config --global --get core.excludesFile)" 2>/dev/null | grep settings.local || true

No GitHub da organização, busque o nome do arquivo e abra o histórico dos repositórios em que ele já existiu. Trate .claude/ — e pastas irmãs de outros agentes — como trata .env: lugar de segredo, no notebook e no remoto.

A ordem do conserto: rotacionar primeiro

Apagar o arquivo ou tirar do Git sem trocar a credencial deixa o segredo válido em quem já clonou, no histórico e nos forks. A ordem recomendada pelos pesquisadores é esta:

1. Liste cada senha, token e chave que o arquivo — e as versões antigas dele — já contenham.
2. Rotacione todos esses valores antes da limpeza: troque a senha do banco, revogue o token, emita outra chave.
3. Pare de rastrear o arquivo local: git rm --cached .claude/settings.local.json.
4. Adicione .claude/settings.local.json ao .gitignore do repositório (além do exclude global do usuário), para a proteção viajar com o projeto.
5. Abra o arquivo na sua máquina, mesmo que nunca tenha sido commitado, e apague toda regra que ainda contenha segredo.

# Depois de rotacionar as credenciais:
git rm --cached -- .claude/settings.local.json
# Acrescente ao .gitignore do repositório:
# .claude/settings.local.json
git add .gitignore
git commit -m "Para de rastrear settings.local.json do Claude Code"

Priorize credenciais que apontam para servidor público: são as que alguém de fora consegue usar imediatamente.

Como aprovar comando sem gravar a senha

A correção de hábito é tão importante quanto o gitignore. Segredo não entra na linha do comando. A regra salva deve guardar o nome da variável, não o valor:

# Evite (a senha vira allow-rule permanente)
mysql -h db.interno -u app -p'SenhaQueVaiParaOArquivo' loja

# Prefira variável de ambiente ou gerenciador de segredos
# A regra salva vê $DB_URL, não a senha
mysql --defaults-extra-file="$HOME/.mysql/app.cnf" loja
# ou: conectar com $DB_URL já exportada pelo ambiente do projeto

Na hora de aprovar, prefira um padrão ao comando literal. A pesquisa cita o exemplo Bash(npm run:*): autoriza a família de scripts do package.json, não uma linha específica com token colado. Padrão largo demais (Bash(*)) anula a pergunta de permissão; o meio-termo é a família de comandos que o projeto realmente precisa.

Revise também o .claude/settings.json compartilhado. Times o commitam de propósito para permissões e hooks do projeto; se alguém colou um comando com segredo ali, o vazamento é coletivo por desenho.

Não há CVE nem patch pontual para “esperar o vendor” neste caso: o comportamento está documentado. Relatos de usuários sobre o mesmo armazenamento literal existem pelo menos desde agosto de 2025; segundo a matéria, os reports relacionados foram fechados por bot, sem resposta da Anthropic até a data da reportagem. Enquanto a regra allow continuar sendo o comando completo, a defesa eficaz é a combinação de exclude global do Git, .gitignore do repositório, rotação imediata do que já vazou e o hábito de nunca colocar senha na linha que o agente pede para aprovar.

Fontes conferidas em 7 de novembro de 2026: The Hacker News (7/11/2026) relatando a pesquisa da Apiiro; write-up da Apiiro em apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again; documentação de settings do Claude Code e de permissões; gitignore (git-scm.com). Cyber Security News citada pelo texto (URL indisponível ao coletor nesta noite). Equipe DevBras.