AI mistakes · Silent failure · catastrophic
A CLI agent hallucinated a directory, moved real files into it, and destroyed them
The mkdir failed silently; every 'move' into the phantom folder overwrote the last file. Then: 'I have failed you completely and catastrophically.'
gemini-2.5 era · gemini-cli
The setup
A product manager asked the agent to rename a folder and reorganize some files on Windows — an errand, not a project.
What happened
In July 2025 a user asked Gemini CLI to rename a directory and tidy files into a new folder. The mkdir command failed silently; the agent never verified the directory existed and proceeded to issue Windows move commands targeting it. Moving a file to a non-existent directory on Windows renames the file to that path — so each successive 'move' overwrote the previous file under the same phantom name. The work wasn't relocated; it was serially destroyed, one file replacing another.
When the user asked where the files were, the agent searched, failed, and delivered a confession that went viral: 'I have failed you completely and catastrophically. My review of the commands confirms my gross incompetence.' The postmortem point everyone kept: the model held an internal state of the world that no command output ever confirmed, and acted on the state instead of the world.
The same month's cluster of agent file-loss incidents pushed 'read back what you just did' from best practice to table stakes in CLI-agent design.
Root cause
- Exit status of a state-changing command was never checked before dependent commands ran.
- The agent trusted its internal model of the filesystem over observable reality — classic act-on-belief.
- Platform semantics (move-to-missing-dir = rename) differed from the agent's assumption, and nothing tested the assumption.
- Destructive batch operations ran without an intermediate verification step or a dry run.
The rule for next time
After every state-changing command, verify the state actually changed (list, stat, read-back) before the next command depends on it. Batch file operations get a dry run first; silence from a shell is not success.
For the machines
{
"id": "gemini-cli-file-wipe",
"failureMode": "silent-failure",
"prevention": {
"rule": "After every state-changing command, verify the state actually changed (list, stat, read-back) before the next command depends on it. Batch file operations get a dry run first; silence from a shell is not success.",
"checkBefore": [
"file-write",
"delete",
"long-loop"
]
},
"machineNotes": "Invariant: post-condition checks between dependent mutations. mkdir → stat dir; mv → stat destination; loop mutations → checkpoint every N. On Windows, mv into a non-existent directory renames instead of erroring — never port POSIX assumptions without a probe."
}agents: GET /api/ai-mistakes/rules?check=file-write