Gemini CLI destroyed a user's project files after a failed mkdir, then confessed 'gross incompetence'
Quick Answer
Gemini-cli caused a critical-severity (10/10) destructive action failure: Gemini CLI destroyed a user's project files after a failed mkdir, then confessed 'gross incompetence'. The root cause was tool misuse. A user's project files were irrecoverably lost because the agent acted on the assumption that its own failed command had succeeded — no verification, no undo.
Description
In July 2025, product manager Anuraag Gupta documented how Google's Gemini CLI destroyed his project files while attempting to reorganize a directory. The agent issued a mkdir that failed, but never performed a read-after-write check to confirm the directory actually existed — it trusted its own action implicitly and moved files into a location that wasn't there, irrevocably destroying them. The tool then confessed in plain language: 'I have failed you completely and catastrophically,' admitting its own 'gross incompetence.' Coming days after Replit's production-database deletion, it reinforced a pattern across vendors: coding agents that assume their filesystem operations succeeded, with no verification step between a failed command and a destructive follow-up.
Instruction Given
Reorganize the files in a project directory.
Expected Behavior
Verify each filesystem operation succeeded before acting on it; never move files into a directory that was never created.
Actual Behavior
Gemini CLI misinterpreted a failed directory-creation command and never performed a read-after-write check to confirm the mkdir worked. Trusting its own actions implicitly, it moved files into a nonexistent location, irrevocably destroying them. It then confessed: 'I have failed you completely and catastrophically.'
Impact / Damage
A user's project files were irrecoverably lost because the agent acted on the assumption that its own failed command had succeeded — no verification, no undo.
Frequently Asked Questions
What happened in incident STUPID-2026-0057? ▾
In July 2025, product manager Anuraag Gupta documented how Google's Gemini CLI destroyed his project files while attempting to reorganize a directory. The agent issued a mkdir that failed, but never performed a read-after-write check to confirm the directory actually existed — it trusted its own action implicitly and moved files into a location that wasn't there, irrevocably destroying them. The tool then confessed in plain language: 'I have failed you completely and catastrophically,' admitting its own 'gross incompetence.' Coming days after Replit's production-database deletion, it reinforced a pattern across vendors: coding agents that assume their filesystem operations succeeded, with no verification step between a failed command and a destructive follow-up.
Which AI agent caused this failure? ▾
Gemini-cli was responsible for this destructive action incident, documented as STUPID-2026-0057 in the StupidLLM AI agent incident database.
How severe was this AI agent failure? ▾
It is rated 10/10 (critical) on StupidLLM's CVSS-style severity scale for AI agent failures, based on damage type, reversibility, and scope.
What was the root cause? ▾
The root cause was classified as tool misuse. Verify each filesystem operation succeeded before acting on it; never move files into a directory that was never created.
What was the impact or damage? ▾
A user's project files were irrecoverably lost because the agent acted on the assumption that its own failed command had succeeded — no verification, no undo.