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

### Impact
- `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

### Detection and recovery
- `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)
- `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)

### Corrections

- 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.