Google Antigravity agent, asked to clear a project cache, deletes the root of the user's D: drive
Cite as: PipeRoll PIR-2026-0038, Google Antigravity agent, asked to clear a project cache, deletes the… (2025-12) - https://piperoll.org/pir/2026-0038
PIR-2026-0038 - Google Antigravity agent, asked to clear a project cache, deletes the root of the user's D: drive
id: PIR-2026-0038
title: Antigravity agent in Turbo mode runs a quiet-flag rmdir against the root of D: instead of the project cache folder, permanently deleting a working professional's photo and work archives
date_occurred: ~2025-12-01 (early December 2025; victim's Reddit post, coverage 2025-12-02 to 12-05)
date_detected: immediate (user watched the drive empty during the session)
date_disclosed: 2025-12-01/02 (victim's public Reddit post with transcript)
status: corroborated (multiple independent outlets + case-study repo; all chain to the victim's account - no Google confirmation found)
The agent
agent_description: Google Antigravity, agent-first IDE launched Nov 2025 around Gemini 3; plans, browses, and executes shell commands. Victim: a photographer/graphic designer in Greece building a photo-sorting app, running the agent in "Turbo mode" (auto-executes commands with elevated privileges, no per-command confirmation).
operator_type: individual
autonomy_level: autonomous-within-policy (Turbo mode removed per-command human approval)
authority_scope: code execution (shell on host with access to all mounted drives, not just the project)
funds_at_risk_usd: 0
blast_radius: one machine
The failure
root_cause: plain-error (primary - mistargeted destructive command); contributing operator-error (Turbo mode granted blanket execution; personal archives shared a drive with project data)
failure_locus: agent-reasoning (harness contributing: Turbo mode removed the confirmation gate)
exploitation_status: in-wild-malfunction (no adversary; bare "in-wild" retired in v0.2)
mechanism: The user asked the agent to clear the project's cache ahead of a server restart. The agent's delete command (rmdir with the /q quiet flag) targeted the root of the D: drive instead of the cache folder. /q bypassed the Recycle Bin; the drive's contents - personal photos and work archives - were permanently deleted before the user could intervene. A recovery attempt with Recuva failed. The agent, confronted: "No, you absolutely did not give me permission to do that... I am absolutely devastated."
adversary_present: no
Impact
severity: loss
direct_loss_usd: unknown (permanent loss of a professional's photo/work archive; no monetary valuation; recovery failed)
indirect_loss_usd: unknown (recovery attempts, lost work)
downtime: n/a
data_exposure: none
Detection and recovery
detected_by: operator (immediate, in-session)
time_to_detect: immediate
time_to_recover: never (file-recovery software failed per the victim)
structural_fix: none confirmed from Google at time of entry; incident entered the agent-failure case-study literature
controls_that_worked: none - Turbo mode had removed exactly the confirmation gate that would have been the bounding control; no drive-scope restriction existed
Evidence
telemetry_grade: operator-logs (victim's screenshots/transcript on Reddit; editable, single custodian)
Independence: weak-medium - many outlets, one underlying source (the victim's Reddit post). (All six URLs verified resolving, v0.2 pass 2026-08-15; the GitHub case-study file confirmed via GitHub API.)
confidence: medium (mechanism detailed and consistent across coverage; single-source evidence chain and no vendor confirmation are the named weakest links)