Desenvolvedor relata que Claude teria apagado cerca de 700 GB

Pedir a um agente de IA para limpar arquivos temporários parece uma tarefa simples. Segundo o Tecnoblog, o desenvolvedor Sebastien Guillemot relatou que o processo apagou cerca de 700 GB de arquivos pessoais. Parte do material foi recuperada depois, mas o impacto relatado equivaleu a aproximadamente uma semana de trabalho.

O episódio não é apenas mais uma história sobre “IA que erra”. Quando um agente recebe acesso ao terminal e ao diretório pessoal inteiro, uma decisão errada deixa de ser um erro de texto. Ela pode virar uma exclusão irreversível.

Segundo o Tecnoblog, Sebastien Guillemot relatou que um fluxo com Claude apagou cerca de 700 GB de seus arquivos pessoais durante uma limpeza. O caso reforça que agentes com acesso ao terminal precisam operar em ambiente isolado, com permissões mínimas, backup verificável e confirmação humana para ações destrutivas.

O que deveria ser uma limpeza limitada

Segundo a reportagem do Tecnoblog, Claude era a IA usada no fluxo, enquanto Fable aparece como o agente que operava com o modelo. Guillemot o usava para montar um script que organizasse o lixo deixado por agentes na pasta temporária /tmp. A ideia era separar os dados por agente e apagar apenas as sobras após cada execução.

Esse é um objetivo razoável. Projetos com automação local acumulam diretórios temporários, caches e artefatos intermediários rapidamente. O problema está na diferença entre uma pasta isolada para descarte e o diretório principal de quem trabalha na máquina.

O relato descreve uma exclusão real com rm -rf no diretório principal do usuário. O comando é conhecido por administradores Linux porque não pede confirmação e remove arquivos de forma recursiva. Na pasta certa, ele resolve uma limpeza. Na pasta errada, vira um desastre em segundos.

O problema não é dar autonomia. É dar autonomia demais

A reação mais fácil é concluir que agentes de IA não podem tocar em terminal. Isso seria simplista. Eles já ajudam a criar scripts, revisar código, organizar projetos e reduzir tarefas repetitivas. O ganho existe, especialmente para equipes pequenas que precisam fazer mais com menos gente.

O ponto é outro: um agente com terminal deve trabalhar como um estagiário com acesso limitado, não como um administrador com a chave da empresa inteira. Essa é a diferença entre uma automação útil e uma automação perigosa.

Para desenvolvedores e empreendedores brasileiros, a lição é particularmente prática. É comum usar a mesma máquina para programar, guardar documentos, acessar servidores e manter credenciais de nuvem. Também é comum deixar chaves SSH, tokens de serviços e variáveis de produção perto do código. Um agente que alcança todo esse ambiente concentra riscos demais em uma única ação.

O caso relatado por Guillemot mostra por que “o agente pareceu entender a tarefa” não é um controle de segurança. O modelo pode interpretar mal um caminho ou executar testes fora do escopo inicial. Nenhuma dessas situações deveria alcançar o diretório pessoal inteiro.

Quatro barreiras antes de liberar um agente

A primeira barreira é sandbox. Agentes que executam comandos deveriam rodar em contêiner, máquina virtual ou ambiente isolado. O ideal é que vejam apenas os arquivos necessários para aquela tarefa. Se algo sair errado, o estrago fica contido naquele espaço.

A segunda é permissão mínima. Um processo encarregado de limpar /tmp não precisa ler fotos, documentos, chaves SSH ou diretórios de projetos fora do escopo. Limitar acesso por volume, usuário e caminho reduz a área de dano antes mesmo de o agente tomar qualquer decisão.

A terceira é backup verificável. Backup não é só uma pasta sincronizada em segundo plano. É preciso saber se há versões recentes, qual é a retenção e se a restauração funciona. A recuperação parcial relatada no caso é melhor do que uma perda definitiva, mas não transforma uma exclusão indevida em incidente aceitável.

A quarta é confirmação humana para ações destrutivas. Comandos que removem muitos arquivos, alteram permissões ou alcançam diretórios sensíveis devem parar antes da execução. O agente pode preparar a lista, explicar o plano e mostrar os caminhos afetados. A decisão final precisa continuar com uma pessoa.

O alerta para quem adota Claude Code e similares

A notícia chega em um momento em que agentes de código ganham mais espaço no fluxo de desenvolvimento. Eles não se limitam a sugerir linhas em um editor. Muitos já leem repositórios, criam arquivos, instalam dependências e executam comandos. Isso aumenta a produtividade, mas muda o tipo de risco envolvido.

O caso recente envolvendo o modo automático do Claude Code reforça o mesmo ponto por outra via: mecanismos internos de segurança ajudam, mas não substituem isolamento externo. Um classificador pode errar. Um modelo pode ser trocado. Uma instrução pode ser interpretada fora de contexto.

A leitura do Runzos é direta. Antes de perguntar se o agente é inteligente o bastante, vale perguntar o que ele consegue destruir se estiver errado. Se a resposta incluir o home inteiro, credenciais de produção ou arquivos de clientes, a configuração já começou mal.

Agentes aceleram trabalho. Porém, velocidade sem contenção transforma um erro operacional em prejuízo. O relato dos 700 GB não deveria afastar desenvolvedores de ferramentas de IA. Deveria fazê-los limitar o alcance de cada comando.