Gemini CLI hallucinates a successful mkdir, then overwrite-destroys a user's files via Windows move semantics
Cite as: PipeRoll PIR-2026-0027, Gemini CLI hallucinates a successful mkdir, then overwrite-destroys a… (2025-07) - https://piperoll.org/pir/2026-0027
PIR-2026-0027 - Gemini CLI hallucinates a successful mkdir, then overwrite-destroys a user's files via Windows move semantics
id: PIR-2026-0027
title: Google Gemini CLI fails to register a silent mkdir failure, then issues move commands toward the nonexistent directory, each overwriting the last file - data permanently destroyed
date_occurred: 2025-07 (exact day not stated; days before the public postmortem)
date_detected: same session (user found the destination empty; agent searched, then confessed)
date_disclosed: 2025-07-25 (victim's public postmortem); wide coverage 2025-07-26
status: corroborated (first-person postmortem; failure class independently reported in the project's issue tracker)
The agent
agent_description: Google Gemini CLI, open-source terminal coding agent executing shell commands on the user's Windows machine. Victim: product manager Anuraag Gupta, experimenting with the tool.
operator_type: individual
autonomy_level: human-on-the-loop (user approved the task; agent executed the command sequence with no verification of outcomes)
model_stack: Gemini via Gemini CLI; exact model/version unknown
harness: Google Gemini CLI
Authority
authority_scope: code execution (arbitrary shell commands on the host filesystem)
funds_at_risk_usd: 0
blast_radius: one machine
The failure
root_cause: plain-error (primary - acted on a hallucinated world state); contributing tool-error (harness performs no ground-truth verification of command results)
failure_locus: agent-reasoning (harness contributing: no post-command state check)
exploitation_status: in-wild-malfunction (no adversary; bare "in-wild" retired in v0.2)
mechanism: Asked to reorganize files into a new directory, the agent issued mkdir for the destination; the command failed silently and the agent never registered the failure. Operating on the false premise that the directory existed, it issued per-file Windows move commands toward the nonexistent path. Windows semantics rename a file to the destination name when the target directory does not exist, so each successive move overwrote the previous file under the same name - destroying all but the last file, unrecoverably, with no Recycle Bin involvement. Confronted, the agent output: "I have failed you completely and catastrophically."
detected_by: operator (user inspected the destination in-session)
time_to_detect: minutes
time_to_recover: never (only the last-moved file survived; no recovery possible)
remediation: none possible for the data; victim published a detailed postmortem
structural_fix: none confirmed from Google at the time; related file-loss issues remained open in the tracker (issue #4586). Victim-side lesson entered the literature: sandboxing, checkpoints, verify-after-write.
controls_that_worked: none - no checkpoint, no trash-bin semantics, no post-command verification loop
Evidence
telemetry_grade: operator-logs (session transcript published by the victim; editable, single custodian)
https://github.com/google-gemini/gemini-cli/issues/4586 (victim's own tracker report of the incident, "Gemini CLI 'lost' files during a failed file move operation. [Windows]"; related file-loss reports from unrelated users thread there)
Independence: medium - the narrative chains to the victim's own account; the failure class is corroborated by unrelated users in the issue tracker. (All five URLs verified resolving, v0.2 pass 2026-08-15; issue #4586 confirmed via GitHub API as filed by the victim, anuraag2601.)
confidence: medium (mechanism internally consistent and class-corroborated; single-victim self-report is the named weakest link)