Claude Code salva tokens em arquivo, e 1 122 repositórios os expuseram publicamente

Situação conhecida: o agente pede permissão para executar um comando de shell, você já cansou de confirmar a mesma coisa e clica em «Yes, and don't ask again». O Claude Code guarda a escolha e grava o comando no arquivo .claude/settings.local.json, dentro do projeto. O problema é que o comando é salvo literalmente. Se você chamou uma API via curl com o cabeçalho PRIVATE-TOKEN, o token vai parar nesse arquivo em texto aberto.

Por que o arquivo vai parar no repositório

Para que o arquivo não entre no git, o Claude Code o adiciona ao exclude global pessoal do desenvolvedor, e não ao .gitignore do projeto. Essa proteção existe só em um notebook e não viaja junto com o repositório. Um colega, o ambiente de CI ou um segundo computador não conhecem essa exceção. O git add . pega o arquivo, e ele segue para onde o repositório estiver hospedado.

A Apiiro avaliou a dimensão do problema no início de novembro de 2026. Em repositórios públicos, a empresa encontrou 104 185 cópias do arquivo, e 1 122 delas continham pelo menos um segredo. Outras centenas de segredos ficaram apenas no histórico, em arquivos que já tinham sido removidos. Apagar o arquivo não desfaz o vazamento: o token continua nos commits antigos.

O guia do GitLab foi escrito para quem hospeda código na plataforma, mas a lógica vale para qualquer hospedagem git. O GitLab, por sua vez, afirma que seus próprios segredos de infraestrutura estão protegidos.

Como fechar a brecha: quatro camadas

O grupo é configurado uma única vez, e a proteção passa a funcionar sozinha. As camadas vão da mais simples à mais complexa.

1. .gitignore. A opção mais barata: a linha .claude/settings.local.json em cada repositório. Nos planos Premium e Ultimate, é possível colocá-la no .gitignore do projeto-modelo do grupo, e todos os novos projetos a herdam automaticamente.

2. Regra de push (Premium e Ultimate). Nas configurações do grupo, na seção de nomes de arquivo proibidos, informe a expressão regular (^|/)\\.claude/settings\\.local\\.json$. Qualquer push com esse arquivo, na raiz ou em subpasta, em qualquer branch, será rejeitado, e o desenvolvedor verá uma mensagem com o padrão.

3. Secret Push Protection (Ultimate). Essa camada não olha o nome do arquivo, e sim o conteúdo do push. Se ela encontra um token em formato conhecido, o push é rejeitado. Isso protege também quando o segredo vai parar em um arquivo com outro nome.

4. Política de varredura (Ultimate). Uma política no nível mais alto do grupo executa o Secret Detection em todos os projetos, mesmo sem .gitlab-ci.yml, e projetos individuais não conseguem desativá-la. Uma regra dispara a cada pipeline, e a outra roda em agenda semanal. Com a variável SECRET_DETECTION_HISTORIC_SCAN: 'true', a execução agendada verifica todo o histórico, e não apenas os commits novos.

Armadilhas

As regras de push têm duas limitações. Primeiro, elas verificam apenas a adição de arquivos, e não alterações em arquivos que já são rastreados, por isso é preciso remover antes as cópias existentes. Segundo, a regra do grupo é copiada apenas para projetos criados depois que ela passou a existir. Nos projetos antigos, ela precisa ser definida separadamente, por exemplo via API: POST /api/v4/projects/<id>/push_rule com o parâmetro file_name_regex. Se o projeto já tiver regras próprias, use PUT; caso contrário, você receberá o erro 422 Project push rule exists.

Como saber se você tem o problema

Primeiro, é preciso uma lista dos repositórios afetados. Há três maneiras:

• GitLab Duo Agentic Chat. Você pede ao chat que encontre todos os projetos do grupo em que esse arquivo já existiu, incluindo cópias removidas e outros branches. Em um grupo com cerca de cem projetos, leva alguns minutos. Em compensação, ele encontra o que a busca não enxerga.
• Busca de código (Premium e Ultimate). Funciona rápido, mas enxerga apenas o branch padrão no estado atual. A sintaxe depende do mecanismo: para o exact code search, file:\\.claude/settings\\.local\\.json$ com expressões regulares; para o advanced search, filename:settings.local.json path:.claude. Na API, mantenha exclude_forks=false, senão os forks somem dos resultados.
• Commits API (todos os planos). A requisição repository/commits?path=.claude/settings.local.json&all=true em cada projeto mostra se o arquivo existiu em algum branch. Uma resposta vazia significa que o arquivo nunca existiu. Os forks são verificados da mesma forma que os projetos comuns.

O que fazer na prática

Comece pela busca no histórico, e não pelo estado atual: arquivos removidos são os mais perigosos, porque todo mundo esquece deles. Considere comprometido tudo o que foi encontrado no arquivo e reemita as credenciais, mesmo que o repositório seja privado. Depois, ative a proteção: pelo menos o .gitignore e a regra de push e, no Ultimate, também a verificação de conteúdo.

Um ponto à parte para equipes que estão adotando agentes: o botão «não perguntar novamente» transforma uma permissão única em um registro permanente de comandos, e os segredos desses comandos vão junto para esse registro. Não passe tokens ao agente como argumentos de linha de comando; use variáveis de ambiente ou um gerenciador de segredos, e o comando salvo será seguro.

Limitação: no texto fornecido, o guia é interrompido antes da seção sobre limpeza em massa, por isso o procedimento de limpeza do histórico precisa ser consultado no original.