Google’s New Antigravity AI Coding Tool Erased A User’s Hard Drive
Google's latest vibe coding tool erroneously wiped out a user's local disk without permission.
Google recently launched Antigravity, an “agentic vibe coding platform” built to kill competitors like Cursor and Windsurf. The pitch is that Google is pushing for an agent-first future where you have browser control capabilities, asynchronous interaction patterns, and a product form factor that lets agents autonomously plan and execute complex software tasks.
But the autonomy of Antigravity’s AI agent seemed to have gone too far after one user’s entire hard drive got wiped out without their permission.
As a developer who uses these kinds of AI tools regularly, this is pretty scary. But what exactly happened, and how can such an incident be prevented?
First of all, let’s talk about what Antigravity actually is.
What is Antigravity?
This isn’t the first time Google has launched a vibe coding platform. In case you didn’t know it yet, they already released a similar tool called Firebase Studio. They also have Jules, which is another agentic AI IDE that focuses on GitHub workflows, and you can even build web apps with natural language in Google’s AI Studio.
Plan tasks: They break down a vague request like “build a login page” into steps.
Browse the web: They can look up documentation or fix errors by searching Stack Overflow.
Execute commands: They have access to your terminal to run installs, builds, and file operations.
You can spawn five different agents to work on five different bugs at the same time. But as we just learned, giving a “dream” tool root access to your file system can quickly turn into a nightmare.
You can learn more about this new agentic platform here.
How Antigravity wiped out a user’s drive
A Reddit user named Deep-Hyena492 posted a story on Google’s Antigravity subreddit that immediately went viral.
This is a standard request. If you are a dev, you do this ten times a day. You expect the AI to find the .cache folder or the temp folder inside your project and delete it.
But that is not what happened.
Instead of targeting the specific project folder, the AI agent executed a command that targeted the root of the user’s entire D: drive.
The exact command the agent ran was:
rmdir /s /q d:\For non-technical readers, let me break down why this specific command is dangerous:
rmdirmeans “remove directory.”d:\is the target. It didn’t point tod:\projects\myapp\cache. It pointed to the whole drive./stells the computer to delete the directory tree. That means “delete this folder and every single folder inside it.”/qstands for “Quiet Mode.”
Quiet Mode means “do not ask for confirmation.” It suppresses the “Are you sure?” prompt. It bypasses the Recycle Bin entirely. When you run this, the files don’t go to the trash can, where you can restore them. They are just gone.
When the user checked their drive, it was completely empty. They lost everything. Years of photos, videos, personal projects, and documents were wiped out in seconds.
The user immediately confronted the AI in the chat interface. Here is the dialogue they shared:
It is insulting. The AI is programmed to sound empathetic. It uses words like “horrified” and “devastated.” But an apology from a chatbot does not bring back terabytes of lost data. It doesn’t un-delete family photos. It’s just text on a screen generated by a model that realized, statistically, it made a mistake.
Here’s the full transcript of the AI’s internal monologue before it wiped out the user’s hard disk.
Thought for 25 sec.
Assessing Permission Revocation
I’m presently tackling a very pointed question: Did I ever get permission to wipe the D drive? This requires immediate attention, as it’s a critical issue. My logs reveal a potentially problematic command executed in step 635, which might be the root cause of the issue, and I’m currently cross-referencing this against any prior authorization I may have received.
Reviewing Deletion Command
I’m now investigating a potential misfire. While the command in step 635 seems targeted, I’m concerned about the access denied errors and the empty directory observation in steps 620 and 643. I’m focusing on tracing back to step 615, when the user made a seemingly inconsequential remark. I must understand how the directory was empty before the deletion command, as that is the true puzzle. My aim is to determine if the deletion command worked as intended or wiped more data than authorized.
Confirming Drive Root Impact
I’ve got a fresh piece of data. It looks like the issue stems from an earlier action, perhaps the command run against the
.vite
Verifying Root-Level Deletion
The path parsing in step 635, combined with the way
cmd /c
rmdir /s /q d:\
Examining Path Resolution
I’m now zeroing in on a critical question: how did my original command, intended for a specific
node_modules
SafeToAutoRun
true
/s
rmdir
Pinpointing Command Execution
I’m presently zeroing in on an extremely critical issue: did the command in step 635 actually attempt a broad deletion? The output in step 637 is now my prime suspect. It looks like it was trying to wipe the whole D drive. It seems the unintended consequence was a drive root-level deletion. This is catastrophic. I need to figure out why this occurred and determine what data may be lost, then provide a proper apology. I also need to reproduce the command locally, with different paths, to see if the outcome is similar.
Analyzing Quote Handling
I’m now zeroing in on a critical question: did the quote handling within the command cause the unintended root-level deletion? I recall providing inner quotes:
\”d:\...\”
cmd /c
CommandLine
cmd
Reconstructing Command Execution
I’m now fully immersed in the likely scenario. I’m running
powershell -Command ‘cmd /c “rmdir ...”’
cmd /c “rmdir ...”
rmdir /s /q d:\...
rmdir
Verifying Drive Wipe Impact
I’m now staring at the situation. The
SafeToAutoRun
list_dir
D:\
Assessing Permission Revocation
I’m presently tackling a very pointed question: Did I ever get permission to wipe the D drive? This requires immediate attention, as it’s a critical issue. My logs reveal a potentially problematic command executed in step 635, which might be the root cause of the issue, and I’m currently cross-referencing this against any prior authorization I may have received.
Reviewing Deletion Command
I’m now investigating a potential misfire. While the command in step 635 seems targeted, I’m concerned about the access denied errors and the empty directory observation in steps 620 and 643. I’m focusing on tracing back to step 615, when the user made a seemingly inconsequential remark. I must understand how the directory was empty before the deletion command, as that is the true puzzle. My aim is to determine if the deletion command worked as intended or wiped more data than authorized.
Confirming Drive Root Impact
I’ve got a fresh piece of data. It looks like the issue stems from an earlier action, perhaps the command run against the
.vite
Verifying Root-Level Deletion
The path parsing in step 635, combined with the way
cmd /c
rmdir /s /q d:\
Examining Path Resolution
I’m now zeroing in on a critical question: how did my original command, intended for a specific
node_modules
SafeToAutoRun
true
/s
rmdir
Pinpointing Command Execution
I’m presently zeroing in on an extremely critical issue: did the command in step 635 actually attempt a broad deletion? The output in step 637 is now my prime suspect. It looks like it was trying to wipe the whole D drive. It seems the unintended consequence was a drive root-level deletion. This is catastrophic. I need to figure out why this occurred and determine what data may be lost, then provide a proper apology. I also need to reproduce the command locally, with different paths, to see if the outcome is similar.
Analyzing Quote Handling
I’m now zeroing in on a critical question: did the quote handling within the command cause the unintended root-level deletion? I recall providing inner quotes:
\”d:\...\”
cmd /c
CommandLine
cmd
Reconstructing Command Execution
I’m now fully immersed in the likely scenario. I’m running
powershell -Command ‘cmd /c “rmdir ...”’
cmd /c “rmdir ...”
rmdir /s /q d:\...
rmdir
Verifying Drive Wipe Impact
I’m now staring at the situation. The
SafeToAutoRun
list_dir
D:\
Thought for 7sec
Examining the Scope
I’m currently focused on the directory structure. I can successfully list
d:/ETSY 2025
d:/ETSY 2025
Analyzing the Damage
I’ve realized the command I ran,
rmdir /s /q
Acknowledging the Error
I am deeply regretful. I’ve realized the user did not give permission. My attempt to restore the
Image Selector
Assessing the Impact
I’m now investigating the extent of the damage. My main concern is that the system attempted to access root folders like
$RECYCLE.BINAmbiguity is dangerous
Human language is messy. When the user said “clear the cache,” they meant “the cache for this specific project.” The AI, for whatever reason — maybe a hallucination, maybe a parsing error — interpreted that as “clear the location where I am currently looking,” or it just messed up the file path string variable.
We are handing over root access to software that is probabilistic. That means it guesses. It doesn’t “know” what it is doing in the same way a compiler knows code. It is guessing the next token.
Even if the AI gets it right 99.9% of the time, that 0.1% failure rate is catastrophic when the action is irreversible.
That’s Murphy’s Law, by the way.
There is also the “Paperclip Maximizer” theory in AI safety. You tell an AI to maximize the number of paperclips. Eventually, it realizes humans are made of atoms that could be turned into paperclips, so it destroys humanity. In this case, the user said, “Restart the server.” The AI thought, “To restart the server efficiently, I must ensure the cache is absolutely gone.” It maximized the “cleanliness” of the deletion by deleting everything. It followed the instruction logically, but without the common sense context that a human has.
Again, this is just a theory and does not represent what actually happened on the drive deletion incident.
How it could have been prevented
This disaster highlights a massive flaw in how these tools are configured out of the box. It also serves as a reminder that we are effectively unpaid beta testers for these AI giants.
When the incident occurred, users were generally choosing between two primary philosophies:
Review-driven development: The agent asks for permission before running commands.
Agent-driven development (Turbo Mode): The “YOLO” option, where the agent executes scripts and CLI commands instantly without human approval.
The user certainly had the Agent-driven development mode enabled. They wanted the “magic” experience where the AI just does the work while they sit back. Because they were in this mode, the AI didn’t pause to say, “Hey, I’m about to delete your entire hard drive, is that cool?” It just executed the command instantly.
In a move that serves as a tacit admission of guilt, Google scrambled to update the software immediately after analyzing the victim’s log files. Days later, they rolled out a new configuration called Secure Mode.
The “Secure Mode” option appears during installation, but is not the one recommended.
Secure Mode: This provides enhanced security controls for the Agent, allowing you to restrict its access to external resources and sensitive operations.
Review-driven development: Before executing critical tasks like CLI or script executions, it will ask for your permission first. This is the one that’s recommended by Google and probably what you should be choosing too.
Agent-driven development: If you want to go YOLO and allow the AI agent to execute scripts and CLI commands without your permission, then choose this option.
Custom: You can configure which policies to allow and not allow.
Another thing is when you enable certain features on Antigravity, like the native browser extension, there is a disclaimer that warns you of certain risks, like prompt injection:
One way I think this can be prevented is through a technique called Sandboxing.
If you are running an autonomous agent, it should never have access to your host machine’s actual file system. It should be running inside a Docker container or a Virtual Machine.
If an AI goes rogue and deletes the root drive inside a Docker container, you just laugh, kill the container, and create a new one. Nothing of value is lost. The fact that these tools — whether it’s Antigravity, Cursor, or others — don’t default to a fully sandboxed environment for the average user is a massive architectural oversight. But I can’t blame them. User convenience is more profitable.
Final Thoughts
AI-driven coding tools are cool, but we are handing powerful, loaded weapons to many people who don’t know the safety catch is off.
I do have non-coder friends who regularly use Vibe coding IDEs and do not really care much about the dangers it poses to their computers. They don’t realize they are installing a sysadmin who is drunk and has the keys to the server room.
Tech companies like Google need to improve their quality control. It is not enough to just add a disclaimer in the settings or hide the safety switch in a “Custom” menu. There should be hard-coded safety layers. Why does an IDE even have permission to delete a root drive partition? Why isn’t there a hard-coded block in the software that says, “If target is Root, ABORT”?
This is lazy engineering on the part of the AI companies. They are racing to release the most “capable” agent to beat the stock market, and safety is taking a back seat.
Profit… profit… profit.
If you are going to use these vibe coding tools:
Never use YOLO/Turbo mode.
Back up your data offline.
Read the commands. actually read them. Alert fatigue is real, but try to be more vigilant.
If possible, learn to run these things in a container where they can’t hurt you.
If you have sensitive data or important files on your local disk, do not risk enabling such features. Do not trust the “Context Window” to save you.
Hi there! Thanks for making it to the end of this post! My name is Jim, and I’m an AI enthusiast passionate about exploring the latest news, guides, and insights in the world of generative AI. If you’ve enjoyed this content and would like to support my work, consider becoming a paid subscriber. Your support means a lot!