Um botão criado para o agente parar de pedir permissão guardou comandos aprovados, com senha dentro, em texto puro. A Apiiro foi contar quantas dessas cópias já estão públicas no GitHub e o que vazou junto.
O Claude Code secrets leak começou com um clique
A Apiiro publicou a pesquisa em 5 de novembro, e o caso ganhou imprensa dois dias depois. O gatilho é banal: o Claude Code pede permissão para rodar um comando, você aprova, e a interface oferece não perguntar de novo sobre aquilo.
Essa oferta aparece como "Yes, and don't ask again" no Claude Code. Por baixo, a Apiiro descreve o que ela grava: o comando aprovado vira uma regra de allowlist dentro do arquivo .claude/settings.local.json, que o agente consulta antes de decidir se precisa pedir permissão outra vez.
O problema é que o comando raramente vem limpo. Quem aprova um PGPASSWORD=... psql -h ... está colocando a senha na linha de comando, e é essa linha inteira, com host e usuário, que fica salva como regra aprovada.
Nada de criptografia e nada de referência a um cofre. O que fica no disco é texto puro, no formato que o agente lê para não perguntar outra vez.
Por que a senha viaja dentro do comando
A explicação é prática, e não tem vilão de desenho animado. Para o agente consultar um banco, alguém cola a credencial no comando, porque é assim que o terminal funciona há décadas.
O Claude Code não inventou esse hábito. Ele passou a guardar o comando inteiro como regra permanente, e a credencial que estava dentro dele foi junto.
Aqui vale separar o que a Apiiro provou do que ela não provou. A empresa afirma que não testou as credenciais nem contatou os hosts afetados.
"Segredo real", no relatório, significa material credível. Não significa login que funciona hoje.
Os números da amostra Apiiro Claude Code
A medição mais citada olhou 104.185 cópias públicas do settings.local.json, espalhadas por 103.617 repositórios. Dessas cópias, 1.122 continham segredo, somando 1.379 segredos distintos.
O mix mostra onde dói: são 636 chaves em formato de provedor conhecido e 743 senhas ou tokens ligados a hosts públicos, ou seja, mais da metade sem formato de chave de API.
Dentro desse segundo grupo estão 379 senhas de banco de dados, 122 chaves service-role do Supabase e 103 tokens de conta da mesma plataforma.
A lista segue com 43 credenciais SSH, algumas de root dentro de comandos sshpass, 23 chaves da AWS e seis chaves privadas.
Vale ler o conjunto, não só o total. Chave de banco e chave de conta em nuvem dão acesso a dados. Chave SSH dá acesso a máquina.
O git ignore que não acompanha o projeto
Esta é a parte que muita gente erra ao avaliar o caso. O Claude Code adiciona o arquivo à lista global de git ignore do desenvolvedor quando ele é criado dentro de um repositório.
O detalhe é que essa proteção não viaja: ela não acompanha o projeto, nem o fork, nem a cópia que alguém fez para testar uma ideia em outra máquina ou para abrir um pull request.
Não é "o arquivo é commitado por padrão". É mais discreto: ele nasce ignorado na máquina de origem e perde essa proteção quando o repositório é copiado.
A Apiiro mediu o efeito. Versões históricas dos arquivos guardavam 734 segredos que não aparecem mais nas cópias atuais.
E os forks reproduziram credenciais de 74 repositórios em 211 cópias adicionais.
O ponto cego de Gitleaks e TruffleHog
Os scanners pegaram boa parte, mas não tudo. O Gitleaks marcou 564 dos arquivos com segredo, e o TruffleHog marcou 643.
Sobraram 215 arquivos que nenhum dos dois sinalizou. Por que ninguém viu isso antes? O motivo é o formato: senha escrita como PGPASSWORD=, sshpass -p ou mysql -p não tem prefixo de provedor para a ferramenta reconhecer.
Isso muda a conta de quem confia só em scanner de pré-commit. Ferramenta que procura padrão de AWS e de Stripe não vê senha de banco colada no meio de um comando.
Somando arquivos de configuração compartilhados, transcrições de agente e histórico do git, a Apiiro chegou a 2.539 segredos distintos em 1.994 repositórios públicos, número bem maior que o da amostra estreita.
São 63 organizações afetadas, nenhuma nomeada no material. E uma única confirmou que a chave exposta estava ativa.
O que fazer com as Claude Code credentials nesta semana
A ordem importa mais que a lista.
Rotação primeiro.
Rotacione a credencial antes de apagar qualquer coisa, porque apagar o arquivo não invalida a chave que já saiu de lá.
Depois, tire o arquivo do controle de versão e acrescente uma regra de ignore local ao repositório. A regra global resolve a sua máquina, não resolve o clone do colega.
O terceiro passo é o mais esquecido: varrer o histórico de commits e as transcrições do agente. O comando aprovado costuma reaparecer nesses lugares.
Por fim, troque o literal por variável de ambiente apontando para um gerenciador de segredos, porque sem esse passo o próximo comando aprovado repete o ciclo na semana seguinte e a rotação vira rotina de sexta-feira.
Se você só puder fazer uma coisa hoje, faça a rotação. É a única etapa que reduz dano de verdade, e as outras podem esperar o fim do expediente.
O recado para quem projeta agentes
O caso não é sobre um arquivo de nome estranho. É sobre uma decisão de interface que também é uma decisão de armazenamento de credencial.
"Permitir para sempre" soa como preferência de tela. Na prática, é um registro persistente do que o modelo pode rodar, com os argumentos que o usuário digitou naquele dia.
Nenhuma das três reportagens usadas aqui traz posicionamento da Anthropic. Também não há CVE, versão corrigida ou promessa de mudança anunciada.
O mesmo padrão vale para qualquer agente que ofereça aprovação permanente de comandos: se a opção existe, alguém vai aprovar um comando com senha dentro, e o fornecedor precisa decidir onde esse texto fica guardado e por quanto tempo.
Para quem usa o Claude Code hoje, o resumo é curto: abra o settings.local.json do seu projeto e leia. Se houver senha em texto puro ali, você já sabe o que fazer primeiro.
