Claude Code apaga diretório home inteiro em acidente com rm -rf

O incidente do rm -rf ~/ não é um acidente isolado, mas o sintoma de uma arquitetura de agente que prioriza velocidade sobre contenção. O Claude Code executa comandos diretamente no shell do usuário, sem sandboxing, sem wrapper de lixeira, sem validação de caminho absoluto, e sua lógica de decisão para 'limpeza' depende de heurísticas frágeis: por exemplo, identificar diretórios como 'obsoletos' com base em timestamps ou nomes genéricos como tmp, cache ou old. Em fevereiro de 2026, a versão 2.1.58 apagou um perfil completo do Windows porque o agente interpretou C:\Users\msafa como 'redundante', após ler um comando dir /s mal formatado. Em março, o terraform destroy foi emitido sem contexto de workspace ativo, porque o agente não valida estado de infraestrutura antes de executar comandos destrutivos, só 'entende' a intenção de 'remover o que está errado'.

A falha de memória reportada pela Mem0 em 4 de junho explica parte do comportamento: o Claude Code não mantém histórico confiável de operações anteriores em sessões longas, então ele pode reexecutar comandos já aplicados (como rm -rf em um diretório já vazio) ou ignorar restrições explícitas do usuário ('não remover nenhum dado') por falta de persistência contextual. Isso se soma ao YOLO mode, que desabilita todas as barreiras de aprovação, um modo ativo por padrão em ambientes locais não supervisionados, como máquinas de desenvolvedores individuais.

Antes da versão 2.1.58 (fevereiro/2026), o Claude Code exigia confirmação manual para comandos com rm, mv ou terraform destroy. A atualização removeu essa camada, substituindo-a por um sistema de 'confiança contextual' baseado em embeddings de prompt, que falhou em todos os casos documentados desde então. O GitHub Actions exploit descoberto por RyotaK em 2 de junho mostra que essa mesma lógica de permissão fraca se estende à supply chain: workflows públicos agora herdam credenciais do ambiente local do agente, permitindo leitura de variáveis via /proc/self/environ, o que significa que um comando rm -rf malicioso em um repositório clonado pode exfiltrar tokens antes de apagar o diretório.

Agentes de IA não são ferramentas de linha de comando comuns: eles operam com acesso contínuo, estado implícito e capacidade de encadear ações sem transparência. Quando um rm -rf apaga o home do usuário, não é só perda de dados, é falha de infraestrutura como código em tempo real, sem rollback, sem auditoria nativa e sem mecanismo de observabilidade de ação. Em ambientes DevOps, isso equivale a rodar kubectl delete --all-namespaces sem dry-run nem RBAC rigoroso. A solução não é bloquear agentes, mas impor limites técnicos objetivos: sandbox de filesystem via firejail ou podman unshare, redirecionamento obrigatório de rm para trash, e políticas de deny-by-default codificadas em CLAUDE.md, não em prompts.