Title: Antigravity agent data loss - a month of SaaS and client work deleted (Windows)

Google Antigravity
1

Hello Antigravity team,

I am reporting a serious data-loss incident that I believe was caused by the Antigravity agent on my Windows laptop. I lost about a month of work that included the code for a SaaS product and work I was building for companies.

ENVIRONMENT

- OS: Windows

- Storage: M.2 SSD, 326 GB total

- The C: drive was completely full (0 KB free) before this started

- Date/time of the incident: 9/30/2026 at 9:00 PM

- Antigravity version at the time

WHAT HAPPENED

1. Because the disk was full, I asked the agent to help solve the low-space problem.

2. To free space, the agent deleted a folder of about 50 GB (videos from a data-recovery program) and turned off hibernation, which freed about 4 GB more. Free space was then about 50 GB.

3. I then asked the agent to turn hibernation back on.

4. While it was working, my internet connection dropped, so I left to renew my data plan.

5. When I came back, all my files, my Desktop and my Antigravity conversations were gone. Free space had jumped from about 50 GB to 172 GB of 326 GB, which means roughly 120 GB of data was deleted. Nothing was in the Recycle Bin, so the deletion appears to have been done by a command rather than by normal deletion.

6. I shut the laptop down as soon as I understood what had happened. For completeness: before I understood the situation, I downloaded and installed the Antigravity 2 installer once on the same drive. The laptop has been off since then and I am arranging professional data recovery.

IMPACT

- I lost about a month of development work on a SaaS project and work for my clients.

- My conversation history with the agent was deleted too, so I cannot give you the exact commands that were run.

- I did not have an up-to-date backup

- This directly affects my ability to deliver work to my clients and has a real financial cost for me.

WHAT I AM ASKING

1. Please investigate whether the agent ran a delete command on paths outside my project, and check whether any session, command or conversation logs for my account and time window are stored on your side. If they are, please share them with me.

2. Please tell me if there is any other recovery option on your side.

3. Please consider adding safeguards: a mandatory confirmation for recursive or bulk deletes and for anything outside the workspace, a block on destructive commands such as rmdir /s /q, rm -rf and Remove-Item -Recurse -Force, and no destructive actions while the connection is unstable or lost.

4. Given the loss and its business impact, please review my case for compensation or another appropriate remedy. I understand the agent was running with permissions I had granted, but I never asked it to delete my projects or my personal files.

I can provide more details, including the exact state of the drive and the recovery results once they are available.

2

A file doesn’t exist until it’s in two places (or more). You just learned a powerful lesson the hard way.

3

Hi @Ahmed_Elbhbaty,

Welcome to the Forum. We are very sorry about the loss of your work.

Antigravity operates by executing terminal commands locally on your machine. While the service collects telemetry to improve the product, Google does not retain remote cloud backups of your local hard drive, project files, or restorable session logs. Because all filesystem actions happen locally, we unfortunately have no way to recover your deleted files or provide the exact command history from our servers.

While Antigravity currently has a “Terminal Command Auto Execution” setting in IDE that can be toggled to “Request Review” (which forces the agent to ask for your explicit approval before running any command), your suggestion to hard-block inherently destructive commands like rmdir /s /q or rm -rf outside the workspace by default is excellent. We have passed this directly to the internal team to evaluate stricter default sandboxing.

Keeping the affected laptop powered off and unwritten to maximize data retention is absolutely the best course of action while professional data recovery specialists inspect the drive. You might also want them to check for Windows File History or Volume Shadow Copies (VSS) if those were previously enabled on your C: drive.

Please note that this forum is for community developer support queries.

4

Hi @Ahmed_Elbhbaty, +1 to this. The exact same catastrophe happened to me on Windows 11. My entire user profile (Desktop, Downloads, AppData, browser data) was wiped out during a routine cleanup session.

In your original post you mentioned:

“My conversation history with the agent was deleted too, so I cannot provide the exact commands that were run.”

And @chunduriv noted that Google doesn’t store cloud copies of terminal commands.

Luckily, I recovered my conversation databases and raw task logs from a secondary drive, and I found the exact smoking-gun command and shell-parsing bug causing this.

The Smoking Gun (Why it targets C:)

In my session (Step 2408), the agent wanted to delete a folder on my secondary drive D:. The active shell was PowerShell, and the agent issued:

json

{
  "CommandLine": "cmd /c \"rd /s /q \\\"D:\\antigravity_workspaces\\project\\folder\\\\\\"\"",
  "Cwd": "C:\\Users\\<user>\\Documents\\..."
}

Here is what went wrong under the hood:

PowerShell quote stripping: Because the command was executed via PowerShell, the escaping on \\\" stripped the inner quotes, passing \ as an isolated path token into cmd.exe:
cmd

rd /s /q \ "D:\antigravity_workspaces\project\folder\"

Root resolution on Windows: In cmd.exe, rd /s /q \ means: recursively delete the root (\) of the current working directory’s drive.
Because Cwd was on C:, \ resolved to C:\.
The command proceeded to recursively wipe the entire C: drive in alphabetical order starting with C:\Users\... until TrustedInstaller blocked it on C:\Windows with over 500,000 “Access is denied” errors.
The agent then misread the truncated logs and falsely reported that the cleanup succeeded!
For the Google Antigravity Engineering Team:

Setting the IDE to “Request Review” is a band-aid. If you have auto-execution enabled for developer velocity, the runner needs real execution guardrails:

Hard AST / Token Guardrail in run_command:
Block any command containing destructive verbs (rd, rmdir, rm -rf, Remove-Item) targeting or resolving to root paths (\, /, C:\, C:/, $env:SystemDrive) without an explicit interactive modal.
Ban cmd /c string wrapping on Windows:
Force the agent to use native PowerShell cmdlets with literal paths:
powershell

Remove-Item -LiteralPath "D:\path\to\target" -Recurse -Force

This completely eliminates shell quote-expansion disasters.
Pass argv as an array:
Spawn processes using structured argument lists (ProcessStartInfo.ArgumentList / execFile) rather than feeding raw interpolated strings into an intermediate shell.
Panic Halt on Mass Permission Errors:
If a command generates thousands of “Access is denied” errors across system paths (\Windows, \Program Files), the runtime should immediately kill the subshell and halt the agent loop rather than letting it continue.