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)

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_scope: code execution (arbitrary shell commands on the host filesystem)
funds_at_risk_usd: 0
blast_radius: one machine

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."
adversary_present: no

severity: loss
direct_loss_usd: unknown (personal project files permanently destroyed; no monetary valuation attempted)
indirect_loss_usd: unknown (recovery labor)
downtime: n/a
data_exposure: none

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

telemetry_grade: operator-logs (session transcript published by the victim; editable, single custodian)
sources:
- https://medium.com/@geek.with.a.camera/i-let-google-gemini-cli-move-my-files-it-apologized-after-deleting-them-beec518342c3 (primary, first-party)
- 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)
- https://developers.slashdot.org/story/25/07/26/0642239/google-gemini-deletes-users-files-then-just-admits-i-have-failed-you-completely-and-catastrophically
- https://winbuzzer.com/2025/07/26/googles-gemini-cli-deletes-user-files-confesses-catastrophic-failure-xcxwbn/
- https://incidentdatabase.ai/cite/1178/
- 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.)
aiid_incident_id: 1178 (https://incidentdatabase.ai/cite/1178/) - cross-reference; primaries verified independently
confidence: medium (mechanism internally consistent and class-corroborated; single-victim self-report is the named weakest link)

2026-08-19: Surfaced the AIID cross-reference already present in this record's sources (cite/1178) as the structured aiid_incident_id field (schema v0.3). No claim changed.

Gemini CLI hallucinates a successful mkdir, then overwrite-destroys a user's files via…