Claude Code expôs senhas em 1.122 arquivos públicos do GitHub com o “Don't Ask Again”

Você já clicou em “Don't Ask Again” uma centena de vezes para o agente parar de interrompê-lo a cada comando. É conveniente. Mas pesquisadores da Apiiro mostraram que essa conveniência tem um preço: foram encontrados 1.122 arquivos com senhas no GitHub público, vazadas especificamente por meio dessas permissões do Claude Code.

Uma ressalva: temos apenas o título e o sinal do Hacker News (114 pontos e 85 comentários), não o texto completo do relatório. Portanto, o mecanismo abaixo é descrito como o mais provável, e os detalhes devem ser conferidos no original.

Como uma senha vai parar no GitHub

Imagine uma sessão típica. Você pede ao agente que se conecte a um banco de dados e execute uma migração. Ele monta um comando no qual a senha aparece diretamente na string de conexão, por exemplo como parâmetro ou variável de ambiente. O Claude Code pede permissão. Você seleciona “Don't Ask Again” para não precisar confirmar isso todas as vezes.

Para lembrar sua escolha, a ferramenta grava uma regra de permissão no arquivo de configurações do projeto. Se a regra estiver vinculada a um comando específico, o comando inteiro, incluindo o segredo, vai parar no arquivo. Daí em diante, tudo segue como sempre: git add, commit, push. O arquivo de configurações fica no repositório ao lado do código e, se o repositório for público, a senha fica acessível a todos.

É importante observar que ninguém fez nada obviamente absurdo. A pessoa não colou a senha no README nem incluiu um arquivo .env em um commit. O segredo vazou como efeito colateral de um recurso conveniente que ninguém considera um local de armazenamento de dados.

Por que isso é mais grave do que um vazamento comum

Scanners de segredos tradicionais procuram padrões conhecidos no código e nos arquivos de configuração do aplicativo. Arquivos de configurações de agentes costumam ser um ponto cego: não são arquivos de código-fonte nem arquivos .env e, por isso, as regras e expectativas da equipe não se aplicam a eles.

Há uma segunda camada do problema. Os agentes inserem credenciais prontamente na linha de comando porque essa é a forma mais simples de concluir a tarefa. Qualquer mecanismo que memorize comandos se transforma em um registro de segredos. Isso não se limita ao Claude Code: os mesmos riscos existem em qualquer assistente que armazene uma lista de ações permitidas junto ao projeto.

O número 1.122 também deve ser interpretado com sobriedade. Foi isso que apareceu em uma busca pública. Repositórios privados, forks e arquivos que já foram excluídos, mas continuam armazenados em cache, não estão incluídos, o que significa que a escala real provavelmente é maior.

O que fazer agora mesmo

Primeiro, localize o diretório de configurações do agente em seus repositórios e examine os comandos permitidos. Considere comprometido tudo o que se pareça com uma senha, um token ou uma string de conexão: primeiro faça a rotação da chave e só depois realize a limpeza. Simplesmente remover a linha do commit mais recente não resolve, pois o histórico do git permanece.

Segundo, separe as configurações compartilhadas das locais. As regras que a equipe deseja compartilhar devem ficar separadas das permissões pessoais, e o arquivo local deve constar no .gitignore.

Terceiro, adicione um scanner de segredos ao pre-commit e à CI e inclua explicitamente os arquivos de configurações de ferramentas de IA na verificação. É uma proteção barata.

Quarto, não forneça segredos ao agente pela linha de comando. Passe-os por variáveis de ambiente fornecidas por um gerenciador de segredos ou por tokens temporários de curta duração. Assim, mesmo um comando memorizado não conterá nada valioso.

A conclusão para equipes de produto e fundadores

Este é um bom exemplo de como a conveniência das permissões em ferramentas de agentes cria uma nova superfície de ataque. Se você está desenvolvendo seu próprio agente, pense exatamente no que é armazenado ao memorizar a escolha do usuário: um modelo de comando ou seu texto literal, e se isso fica em um arquivo que, por padrão, será incluído no git. Mascarar segredos antes da gravação e manter o arquivo em um local seguro exige alguns dias de trabalho; um vazamento em mil repositórios custa muito mais.