Claude Code deixou passwords e chaves expostas no GitHub: o que fazer

Um atalho pensado para poupar cliques no Claude Code, o assistente de programação da Anthropic, está a deixar passwords, chaves de API e acessos a bases de dados à vista em repositórios públicos do GitHub. Duas empresas de segurança, a Apiiro e a GitGuardian, publicaram em novembro de 2026 análises independentes sobre o mesmo ficheiro, o .claude/settings.local.json, e o tema chegou esta semana à imprensa portuguesa, com a Pplware. Se a sua empresa, ou a agência que lhe faz o site, usa o Claude Code, convém verificar hoje. Explicamos o que aconteceu, o que está confirmado e o que fazer.

O que acontece quando escolhe «não voltar a perguntar»

Por defeito, o Claude Code pede autorização antes de correr comandos na consola. Uma das respostas possíveis é «Yes, and don't ask again» («sim, e não voltar a perguntar»). Quando o programador escolhe essa opção, a ferramenta grava uma regra de autorização no ficheiro .claude/settings.local.json, dentro da pasta do projeto, segundo a descrição da The Hacker News com base na documentação de permissões.

O problema está no que fica gravado. Por vezes a regra é um padrão genérico, como npm test *. Outras vezes é o comando exato, palavra por palavra. Se esse comando incluía uma password ou uma chave de API, por exemplo num pedido curl com um cabeçalho de autenticação, o segredo fica guardado no ficheiro em texto simples.

O Claude Code tenta manter este ficheiro fora do Git: na primeira vez que o escreve, adiciona-o às exclusões globais do Git daquele computador. Mas, como notam os investigadores, essa proteção não viaja com o projeto. Não é acrescentada ao .gitignore do repositório, não protege um ficheiro que já estava a ser seguido pelo Git e não se aplica noutra máquina ou num clone antigo. Nesses casos, o ficheiro é enviado com o resto do código.

Os números da Apiiro e da GitGuardian

A Apiiro publicou a sua análise a 5 de novembro. Segundo a The Hacker News, encontrou 104 185 cópias públicas do ficheiro em 103 617 repositórios. Cerca de 1,1%, ou seja, 1122 cópias, continham pelo menos um segredo, num total de 1379 segredos diferentes. Mais de um terço dava acesso direto a bases de dados, incluindo 379 passwords de bases de dados, 43 acessos SSH a servidores públicos, 42 tokens de GitHub, GitLab e npm e 23 chaves da AWS. A Apiiro identificou 63 organizações afetadas e não testou se as credenciais ainda funcionavam, embora uma empresa contactada tenha confirmado que a sua chave estava ativa.

A GitGuardian, que analisa continuamente os envios públicos para o GitHub, publicou a 9 de novembro um relatório mais abrangente. Entre janeiro de 2025 e 7 de novembro de 2026, contou 31 088 segredos distintos neste ficheiro, em 23 276 repositórios. Destes, 5343 funcionavam no momento da deteção. As duas contagens não se contradizem: a Apiiro mediu o que está exposto hoje, com filtros conservadores, e a GitGuardian contou tudo o que alguma vez foi enviado, incluindo versões já apagadas.

Há um pormenor que interessa a quem tem sites e aplicações: segundo a GitGuardian, as credenciais que ainda funcionam são sobretudo de bases de dados. Só neste ficheiro havia 1955 ligações Postgres válidas, 292 passwords SSH válidas e 941 chaves Google API válidas. Entre o que fica gravado em comandos curl e prefixos como DATABASE_URL= aparecem também chaves service-role e tokens do Supabase, que dão acesso total à base de dados de uma aplicação.

Não fica só no GitHub

A GitGuardian encontrou também estes ficheiros em imagens públicas do Docker Hub: 613 segredos distintos, 99 válidos, em 543 repositórios de imagens. A explicação é simples: uma instrução COPY . . num Dockerfile copia a pasta de trabalho inteira e ignora as regras do Git. Se o .dockerignore não excluir a pasta .claude/, o ficheiro vai dentro da imagem. A Apiiro lembra que o mesmo pode acontecer com pacotes npm, arquivos zip ou pastas sincronizadas.

Outro dado que pesa: a Apiiro correu os detetores gitleaks e TruffleHog sobre os 1122 ficheiros com segredos e 215 não foram assinalados por nenhum. A maioria das falhas são passwords escritas no meio de comandos, que não têm o formato reconhecível de uma chave de um fornecedor.

O que diz a Anthropic

Segundo a GitGuardian, que cita o iTnews, o responsável pelo Claude Code, Boris Cherny, respondeu no Hacker News que a equipa está a analisar o problema, que a ferramenta não tem limpado segredos destas regras e que estão em teste um modo automático e uma deteção de segredos integrada, que podem não resolver tudo. Disse também que o Claude Code coloca o ficheiro no gitignore quando o cria, pelo que as cópias expostas terão sido criadas ou enviadas manualmente. A GitGuardian contesta essa leitura: nas cerca de 3000 ocorrências que inspecionou, todos os segredos estavam em regras com o formato exato que o pedido de autorização escreve. Não encontrámos, até à data, um comunicado oficial da Anthropic com uma correção.

O que fazer agora

Apagar o ficheiro do repositório não resolve: o histórico do Git, os forks e as imagens Docker já publicadas guardam cópias. As duas empresas dão a mesma ordem de prioridades:

1. Procurar .claude/settings.local.json e .claude/settings.json em todos os repositórios da empresa, incluindo o histórico, mesmo onde o ficheiro já não existe.
2. Rodar primeiro todas as passwords, tokens e chaves que o ficheiro alguma vez teve: bases de dados, SSH, chaves de API, Supabase, cloud. Só depois limpar.
3. Deixar de seguir o ficheiro com git rm --cached .claude/settings.local.json e acrescentar .claude/ ao .gitignore e ao .dockerignore do próprio projeto.
4. Abrir o ficheiro local (ou usar o comando /permissions) e apagar todas as regras que contenham segredos.
5. Deixar de colar segredos em comandos: usar variáveis como $DATABASE_URL, para que a regra guarde o nome e não o valor, e preferir regras com padrões estreitos em vez de comandos exatos ou autorizações largas como Bash(curl:*).
6. Tratar as pastas de agentes (.claude/, .cursor/, .gemini/, .codex/) e ficheiros como CLAUDE.md como se fossem um .env, com verificação de segredos antes de cada envio e no CI.

O que isto significa para uma PME

A maioria das PME não programa com o Claude Code, mas muitas têm o site, a loja online ou a aplicação feitos por freelancers e agências que já usam assistentes de IA. Vale a pena fazer uma pergunta direta a quem gere o seu código: usam o Claude Code ou outro agente, os repositórios são públicos e já verificaram estes ficheiros? Se a resposta for incerta, peça a rotação das credenciais da base de dados e do alojamento. É o mesmo raciocínio que deixámos sobre chaves e agentes de IA e sobre aplicações feitas com IA que expõem dados: a ferramenta acelera o trabalho, mas os segredos continuam a ser responsabilidade de quem a usa.

Se suspeitar que uma chave já foi usada por terceiros, siga os passos do nosso guia sobre o que fazer nas primeiras horas. E se quer ver o que o seu site e o seu domínio mostram a quem procura uma porta de entrada, a auditoria gratuita da MarcaWeb dá-lhe um primeiro retrato em poucos minutos.