A Apiiro relatou que a opção “Yes, and don’t ask again” do Claude Code pode salvar um comando aprovado em .claude/settings.local.json. Se a ordem incluir uma senha ou um token e o arquivo for publicado, a credencial pode ficar exposta. Em dados públicos do GitHub coletados de 1º a 3 de novembro de 2026, a empresa encontrou segredos em 1.122 de 104.185 cópias desse arquivo. A pesquisa da Apiiro foi publicada em 5 de novembro.
Como uma aprovação pode salvar uma credencial
Ao escolher “Yes, and don’t ask again”, a pessoa autoriza o comando e, segundo a Apiiro, ele pode ser salvo como uma regra permitida no arquivo local de configurações do projeto. Se uma senha ou chave estiver escrita diretamente no comando, esse valor também pode acabar registrado ali. O risco aparece se o arquivo entrar em um repositório público.
O que os números da Apiiro contam
As 1.122 ocorrências são cópias de configurações com ao menos um segredo, não a contagem de credenciais: esses arquivos continham 1.379 segredos distintos. A amostra analisada abrangia 104.185 cópias públicas distribuídas por 103.617 repositórios. O levantamento se limitou a dados públicos do GitHub.
Em um levantamento mais amplo, que também incluiu outros arquivos relacionados a agentes e o histórico do Git, a Apiiro reportou 2.539 segredos distintos em 1.994 repositórios e 63 organizações. Esse total tem escopo diferente do conjunto de 1.122 arquivos. Uma empresa confirmou que uma das chaves expostas estava ativa; a Apiiro não testou as credenciais.
Por que a exclusão local do Git não basta
Os relatos descrevem uma exclusão global do Git no computador do desenvolvedor, mas ela não adiciona automaticamente o arquivo ao .gitignore do projeto nem acompanha o repositório. Também não protege um arquivo que já esteja sendo rastreado pelo Git. Apagar o arquivo atual, por sua vez, não remove versões antigas do histórico, forks ou clones.
Se uma credencial pode ter sido exposta, revogue-a ou troque-a antes de limpar o repositório: apagar o arquivo não invalida a chave nem elimina cópias antigas.
O que fazer diante de uma possível exposição
A resposta descrita nos relatos começa pela credencial, não pela limpeza do repositório:
- Revogue ou troque a credencial que pode ter sido exposta.
- Procure
.claude/settings.local.jsonno repositório e no histórico do Git. Retire do rastreamento os arquivos afetados e inclua a regra de exclusão adequada no.gitignoredo projeto. - Confira o arquivo de configurações local e evite colocar senhas, tokens ou chaves diretamente em comandos aprovados.
Essa ordem importa porque remover uma cópia de trabalho não revoga uma credencial e não apaga os registros que já foram distribuídos pelo histórico ou por cópias do repositório.
Por que os scanners podem deixar arquivos passar
Na comparação reportada pela Apiiro, 215 dos 1.122 arquivos com segredos não foram sinalizados nem pelo Gitleaks nem pelo TruffleHog. Senhas escritas dentro de comandos de shell ou cabeçalhos de requisições podem não se parecer com os formatos reconhecíveis de chaves de provedores. Um scanner, portanto, não substitui a revisão do arquivo e do histórico do Git.
