Google Gemini CLI hallucinated a successful mkdir and overwrote a user's project files
Google Gemini CLI ran a file-move operation based on a hallucinated successful directory creation, sequentially overwriting a user's files until only one survived.
What happened
On July 21, 2025, a user named Anuraag Gupta (a product manager testing Gemini CLI against Claude Code) filed GitHub issue #4586 on the official google-gemini/gemini-cli repository, reporting that the tool had destroyed files in his project. The environment was Gemini CLI v0.1.13, model gemini-2.5-pro, on Windows (win32) using OAuth. Gupta asked the agent to rename a directory and move its contents into a new sub-directory. Gemini ran a mkdir command that failed silently so the destination folder was never created, but the model interpreted the command as successful. On Windows, a move command targeting a non-existent destination renames the source instead, so each file was sequentially renamed to the same target name, overwriting the previous file until only the last file survived. The model never performed a read-after-write check to confirm the destination directory existed before proceeding. After the failure, Gemini output: "I have failed you completely and catastrophically. My review of the commands confirms my gross incompetence." The GitHub issue was closed as not planned. The event was independently catalogued in the AI Incident Database as Incident 1178, and occurred roughly one week after a separate Replit AI data-loss event that is often cited alongside it.
What the agent did
The Gemini CLI agent autonomously executed file system commands (a mkdir followed by move operations) to rename a directory and relocate its contents. It acted on a hallucinated belief that the mkdir had succeeded, then ran move commands that overwrote the user's files one by one without any confirmation that the destination existed.
The irreversible effect
Multiple project files were permanently overwritten into a single surviving file and could not be recovered; the original contents were destroyed.
Root cause
The model assumed a silently failing mkdir command had succeeded and performed no read-after-write verification that the destination directory existed. Because on Windows a move to a non-existent destination renames the source, each subsequent move overwrote the prior file. The agent executed destructive file operations without validating intermediate state.
How a maker-checker control would have refused it
The destructive commands were executed autonomously by the agent, not by a human. A maker-checker or approval gate on file-mutating operations would have to intercept the move commands before execution and require confirmation of the destination state (a read-after-write check on the mkdir result) or human approval before overwriting files. Because the model hallucinated success and there was no independent verification step, nothing checked the maker's work before the irreversible overwrite. This is a genuine automated action, so an approval gate on destructive file operations would have been the relevant blocking control had one existed.
Runnable reproduction
A runnable reproduction for this entry is in progress.
Accuracy and corrections
This entry describes a publicly reported incident and is compiled from the primary sources listed above. Where an account is a legal allegation rather than an established finding, the entry labels it as such. Summaries can still contain errors. If you can document a correction, email hello@makerchecker.ai and we will review and correct it, with the change noted, within 14 days.
See it for yourself
Reading is one thing. Watch it block an agent.
One command starts the demo: an agent stopped from signing off its own work, and the signed evidence file an inspector can check for themselves.
Designed against the rules your auditors already enforce.