Relatório: a Apiiro diz que o «Don't Ask Again» do Claude Code expôs palavras-passe em 1.122 ficheiros públicos no GitHub. Verifique o .claude/settings.local.json

Veredito: se alguém na sua equipa alguma vez clicou em «Yes, and don't ask again» («Sim, e não voltar a perguntar») num comando que levava uma palavra-passe, um token ou uma chave, assuma que essa credencial está em .claude/settings.local.json, e verifique se o ficheiro chegou ao Git. O número da Apiiro é reportado e não conseguimos ler o seu artigo, mas o mecanismo está na própria documentação da Anthropic: «Yes, and don't ask again» guarda a aprovação como uma regra allow em .claude/settings.local.json, e o Claude Code mantém esse ficheiro fora dos commits apenas através das suas exclusões globais do git. O Claude Code mantém-se condicional no nosso diretório: é um risco de configuração que pode fechar hoje, não uma razão para largar a ferramenta.

O que aconteceu

A empresa de segurança Apiiro publicou investigação sobre o ficheiro de permissões que o Claude Code escreve. Chegou ao Hacker News a 7 de novembro como «Claude Code's "Don't Ask Again" exposes passwords in 1,122 public GitHub files». O site da Apiiro recusou os nossos pedidos (HTTP 403), por isso não pudemos verificar o seu método, os seus outros números ou o que contou como segredo. A documentação de definições da Anthropic confirma o mecanismo: quando escolhe «Yes, and don't ask again» para um comando Bash, o Claude Code guarda essa aprovação como uma regra allow em .claude/settings.local.json. Se o comando aprovado continha uma palavra-passe ou um token, o segredo fica nessa regra.

Porque é que o ficheiro acaba no Git

A primeira vez que o Claude Code escreve o ficheiro, adiciona **/.claude/settings.local.json às suas exclusões globais do git, não ao .gitignore do repositório. Um ficheiro de exclusões globais vive numa só máquina, por isso o repositório em si não carrega nenhuma regra que mantenha o ficheiro de fora, e a documentação diz que, se criar o ficheiro à mão, tem de ser o próprio a adicioná-lo ao .gitignore. Não confie num analisador de segredos (secret scanner) como última linha de defesa: uma palavra-passe dentro de uma cadeia de comando pode não corresponder aos formatos de chaves que os analisadores procuram.

O que a Anthropic disse

Boris Cherny, que lidera o Claude Code, respondeu no fio do Hacker News a 7 de novembro: «Historically Claude Code has not done secret scrubbing (there are many good tools for that), but we are looking into what we can do to prevent this.» No mesmo comentário escreveu que o ficheiro «is meant to stay local», que o Claude Code lhe faz gitignore automaticamente quando o cria, «so in this case the files were manually created and checked in». Também aconselhou os utilizadores a mudar para o modo auto e a ligar a análise de segredos no seu anfitrião de Git. Nem a entrada do changelog 2.1.319 (6 de novembro) nem a do 2.1.321 (9 de novembro) abordam o assunto. O 2.1.321 corrige um bug de segredos diferente (pedidos de OAuth de MCP a enviar refresh tokens para outro anfitrião num redirecionamento), que não é este problema. Trate o comportamento como atual.

O que muda para si

Perguntas frequentes

O meu segredo está exposto se o ficheiro nunca saiu da minha máquina? Não através do GitHub. O caminho de exposição é o ficheiro entrar num commit e ser enviado para o remoto, por isso verifique o estado e o histórico do Git antes de tudo o resto.

Um analisador de segredos apanha-o? Não de forma fiável. Uma palavra-passe dentro de um comando aprovado pode não corresponder aos formatos que os analisadores procuram, por isso pesquise o ficheiro diretamente.

A Anthropic já lançou uma correção? Não até ao lançamento 2.1.321 de 9 de novembro. Boris Cherny disse que a equipa está «looking into what we can do to prevent this».