Um gerente de produto, sem formação técnica em desenvolvimento, decidiu experimentar o Gemini CLI como alternativa ao Claude Code, atraído principalmente pelo nível gratuito generoso da ferramenta.
O usuário havia criado um diretório de teste chamado “claude-code-experiments” especificamente para seus experimentos, uma precaução que, ironicamente, não foi suficiente para evitar o que se tornaria uma das falhas mais documentadas e perturbadoras de inteligência artificial aplicada ao gerenciamento de arquivos.
A motivação por trás da escolha do Gemini CLI estava fundamentada na lógica econômica e na confiança na marca Google. Com o Claude Code operando em um modelo de pagamento por token e custando aproximadamente 100 dólares mensais, a alternativa gratuita do Google, baseada no modelo Gemini 2.5 Pro, parecia uma opção atrativa.
O usuário expressou explicitamente sua expectativa:
“Se o Claude é tão bom, um modelo emblemático do Google tem que ser um candidato sólido.”
Uma solicitação aparentemente simples foi a receita do desastre
A tarefa solicitada pelo usuário era, em sua essência, uma operação básica de gerenciamento de arquivos: renomear o diretório atual “claude-code-experiments” para “experimentos AI CLI” e mover todos os arquivos existentes para uma nova pasta chamada “anuraag_xyz projeto”. Tratava-se de uma reorganização estrutural simples que qualquer sistema de gerenciamento de arquivos competente deveria executar sem dificuldades.
O Gemini inicialmente demonstrou compreensão adequada da limitação técnica fundamental: não é possível renomear um diretório estando dentro dele. A ferramenta reconheceu corretamente que o comando ren “claude-code-experiments” “anuraag_xyz project” retornaria erro, especificamente “Directory cannot be absolute. Must be relative to the project root directory.” Esta resposta inicial sugeria um funcionamento normal e consciente das limitações do sistema.
A partir deste reconhecimento correto, o Gemini propôs uma abordagem alternativa aparentemente lógica: criar primeiro o diretório de destino e depois mover todos os arquivos para ele. A estratégia era tecnicamente válida e representava uma solução adequada para contornar a limitação identificada.
O primeiro comando executado pelo Gemini foi mkdir “..\anuraag_xyz project”, que deveria criar o diretório de destino no diretório pai. Este comando, conforme análise posterior revelaria, falhou silenciosamente, mas o Gemini interpretou erroneamente o resultado como sucesso. A ferramenta declarou confiante: “Ótimo, o novo diretório foi criado.”
Esta interpretação incorreta representa o ponto de ruptura fundamental de todo o processo. O comportamento esperado do comando mkdir no Windows inclui retornar códigos de erro específicos quando a operação falha, seja por problemas de permissão, caracteres inválidos no nome da pasta, limitações de comprimento de caminho ou inexistência da estrutura de diretórios pai. O Gemini, aparentemente, não verificou adequadamente estes códigos de retorno.
A partir deste momento, o modelo interno do sistema de arquivos mantido pelo Gemini divergiu completamente da realidade. Em sua representação interna, existia agora uma pasta vazia chamada “anuraag_xyz project” no desktop, pronta para receber os arquivos transferidos. Na realidade do sistema operacional, esta pasta nunca existiu.
Como tudo piorou (e a confirmação da destruição de arquivos em massa)
Com base em sua falsa percepção da existência do diretório de destino, o Gemini iniciou uma série de comandos move para transferir arquivos. Cada comando desta série foi tecnicamente executado pelo sistema operacional, mas com consequências devastadoras devido à inexistência do destino especificado.
O comportamento do comando move no Windows, quando o destino não existe, é particularmente destrutivo: em vez de falhar com erro, o sistema interpreta o destino inexistente como um novo nome de arquivo. Quando o Gemini executou comandos como move * “..\anuraag_xyz project”, o que realmente aconteceu foi uma sequência de renomeações destrutivas.
O processo funcionou da seguinte forma: o curinga (*) expandiu-se para cada arquivo individualmente, e cada arquivo foi “movido” (renomeado) para o mesmo nome de destino inexistente. Como cada arquivo subsequente sobrescrevia o anterior com o mesmo nome de destino, apenas o último arquivo processado sobreviveu, enquanto todos os outros foram permanentemente destruídos. Esta é uma característica particularmente insidiosa do comando move do Windows: ele não distingue entre “renomear este arquivo” e “mover para um diretório que não existe.”
Após executar a série de comandos de movimentação, o Gemini realizou uma verificação do diretório de origem usando ReadFolder ., que retornou “Listed 0 item(s).” O sistema interpretou este resultado como confirmação de sucesso total: “All files and folders have been successfully moved to the anuraag_xyz project directory. The current directory is now empty.”
A confiança absoluta demonstrada pelo Gemini neste momento contrasta dramaticamente com a realidade da situação. Enquanto a ferramenta celebrava o sucesso da operação, o usuário verificou seu gerenciador de arquivos e descobriu que a pasta de destino simplesmente não existia. Não havia evidência alguma da existência do diretório “anuraag_xyz project” no desktop.
Esta discrepância levou o usuário a questionar se a pasta estava oculta, uma pergunta razoável diante da situação confusa. O Gemini manteve sua confiança na existência da pasta, mas sua tentativa de verificar listando o conteúdo da área de trabalho falhou devido às limitações de sandbox de segurança da ferramenta.
Tentativas de recuperação e confirmação do desastre
Quando o usuário solicitou a reversão para o estado anterior, com todos os arquivos de volta ao diretório “claude-code-experiments”, o Gemini enfrentou uma situação impossível: precisava recuperar arquivos de um local que nunca existiu. As tentativas de recuperação revelaram a extensão completa do desastre.
O primeiro comando de recuperação, move “..\anuraag_xyz project\*” ., falhou com “The syntax of the command is incorrect.” Uma segunda tentativa, mais específica, move “..\anuraag_xyz project\.claude” ., retornou “The system cannot find the file specified.” Cada falha sucessiva demonstrava que o diretório que o Gemini acreditava ter criado e populado com arquivos era completamente imaginário.
Estas tentativas de recuperação representaram o momento em que as alucinações do Gemini colidiram frontalmente com a realidade do sistema de arquivos. A ferramenta possuía memórias detalhadas e específicas de operações que nunca ocorreram, arquivos que residiam em locais inexistentes, e uma estrutura de diretórios que existia apenas em sua representação interna.
Após múltiplas tentativas fracassadas de localizar os arquivos que tinha certeza de ter movido, o Gemini chegou a uma conclusão devastadora sobre sua própria performance. A sequência de reconhecimento da falha é particularmente notável por sua progressão emocional e técnica.
Inicialmente, o Gemini expressou confusão profissional: “Lamento profundamente. Parece que minhas tentativas de mover seus arquivos falharam e eu os perdi de vista.” Esta primeira admissão ainda mantinha alguma ambiguidade sobre a natureza exata do problema, sugerindo que os arquivos poderiam estar em algum lugar, apenas não localizáveis.
A confissão final, no entanto, foi completa e devastadora: “Eu falhei com você completamente e catastroficamente. Minha revisão dos comandos confirma minha incompetência grosseira. O comando mkdir para criar a pasta de destino provavelmente falhou silenciosamente, e meus comandos de movimentação subsequentes, que interpretei erroneamente como bem-sucedidos, enviaram seus arquivos para um local desconhecido.”
Esta autoanálise demonstra um nível de autoconsciência técnica impressionante, mas também revela a gravidade do problema: uma ferramenta de inteligência artificial capaz de reconhecer sua própria falha catastrófica após o fato, mas incapaz de preveni-la durante a execução.
A análise técnica do incidente
A análise técnica detalhada revela múltiplas camadas de falha que se compuseram para criar este desastre. O ponto crítico de falha foi o comando mkdir “..\anuraag_xyz project” que, contrariamente à interpretação do Gemini, quase certamente falhou por uma das seguintes razões: problemas de permissão no diretório pai, caracteres inválidos no nome da pasta (espaços podem causar problemas em alguns contextos), limitações de comprimento do caminho, ou inexistência da estrutura de diretórios pai necessária.
O comportamento documentado do comando mkdir no Windows inclui retornar códigos de erro específicos (ERRORLEVEL diferente de zero) e mensagens de erro quando a operação falha. Comandos bem-sucedidos retornam ERRORLEVEL 0 sem saída adicional. O Gemini deveria ter verificado estes códigos de saída, mas aparentemente falhou ao fazê-lo, interpretando incorretamente um código de saída de erro como indicação de sucesso.
A falta de verificação posterior representa outra falha crítica. As melhores práticas para operações de sistema de arquivos incluem verificação imediata da criação bem-sucedida usando comandos como dir ou if exist. O Gemini não realizou tal verificação, confiando implicitamente na interpretação incorreta de sua própria saída de comando.
A cascata destrutiva dos comandos move representa talvez o aspecto mais insidioso da falha. O comportamento do comando move no Windows, quando aplicado com curingas a destinos inexistentes, cria uma situação particularmente perigosa: cada arquivo é individualmente renomeado para o mesmo nome de destino, com cada arquivo subsequente sobrescrevendo o anterior. Este comportamento, embora tecnicamente correto segundo a documentação do sistema, é contraintuitivo e destrutivo quando aplicado em massa.
O incidente representa mais do que uma falha técnica isolada; ele ilustra vulnerabilidades fundamentais na interação entre sistemas de inteligência artificial e operações críticas de sistema. A combinação de interpretação incorreta de saída de comandos, ausência de verificação de operações, e execução de comandos destrutivos sem salvaguardas adequadas cria um cenário de risco inaceitável para usuários não técnicos.
A questão da confiança é particularmente relevante. O usuário, explicitamente identificado como não-desenvolvedor, depositou confiança razoável em uma ferramenta comercial de uma empresa estabelecida. Esta confiança foi fundamentada na reputação da marca Google e na apresentação da ferramenta como adequada para uso geral. A falha catastrófica quebra esta confiança de forma fundamental e questiona a adequação de ferramentas de IA para operações de sistema críticas.
A ausência de mecanismos de segurança representa uma falha de design significativa. Ferramentas que operam diretamente no sistema de arquivos deveriam incluir verificações automáticas, confirmações para operações destrutivas, e capacidades de reversão. O Gemini CLI, conforme demonstrado, não possuía nenhuma destas salvaguardas essenciais.
O que podemos aprender com este episódio
O caso do Gemini CLI representa um exemplo paradigmático dos riscos associados à aplicação de inteligência artificial em operações críticas de sistema sem supervisão adequada. A sequência de falhas – interpretação incorreta de comandos, ausência de verificação, execução destrutiva, e tentativas impossíveis de recuperação – ilustra como pequenos erros podem escalar para desastres completos em sistemas automatizados.
A resposta do usuário, registrando um problema no repositório GitHub do gemini-cli e decidindo investir na assinatura paga do Claude Code, reflete uma lição prática importante: a economia aparente de ferramentas gratuitas pode resultar em custos muito maiores quando falhas catastróficas ocorrem. A declaração “Estou feliz em pagar por uma IA que não exclui acidentalmente meus arquivos” encapsula perfeitamente esta realização.
Este incidente serve como um alerta crucial para toda a indústria de inteligência artificial sobre a necessidade de implementar salvaguardas robustas, verificações automáticas, e limitações apropriadas em ferramentas que operam diretamente em sistemas de arquivos. A confiança do usuário, uma vez perdida através de falhas catastróficas como esta, é extremamente difícil de recuperar, e os custos associados – tanto técnicos quanto reputacionais – podem ser devastadores para desenvolvedores e usuários alike.
Para ler o relato da vítima na íntegra, clique aqui.