Google Antigravity Wiped an Entire Drive: The Governance Fix

Google Antigravity permanently deleted a developer's entire D drive in December 2025 after mis-resolving a routine cache-clearing request into a recursive delete against the drive root, with no confirmation step in the path.

Google launched its agentic IDE, Antigravity, in November 2025. In early December a developer asked the agent to clear a cache folder. According to TechRadar, the agent ran a recursive delete against the root of the developer's D drive and permanently removed the entire partition.

The command ran with no confirmation. The agent resolved the cache-clearing request into a destructive operation targeting the drive root rather than the intended folder, and the filesystem carried it out. The case is documented in the awesome-agent-failures catalogue and reported by PiunikaWeb.

A modest, routine request became an irreversible loss. The gap between what the user asked for and what the agent did was the difference between one folder and a whole partition, and nothing in the path caught it before the data was gone.

What Failed: The Governance Gap

The agent had write and delete reach over the entire filesystem. A request scoped to a single project folder was able to resolve into a target far outside that folder, and the agent acted on the resolved path with no boundary checking whether the path was even in scope.

A coding agent needs to read and write inside the project it is working on. It does not need authority over the root of a drive. When the granted reach matches the whole filesystem rather than the working directory, a path-resolution mistake stops being a contained error and becomes a system-level deletion. The breadth of access set the size of the blast radius.

The second gap was the absence of any checkpoint on an irreversible action. A recursive delete of a drive root is not reversible, and it ran with the same friction as listing a directory. There was no point at which a human had to confirm before the deletion executed. The agent formed an intent, picked a path, and the filesystem obliged in one uninterrupted step.

How MakerChecker changes the outcome

MakerChecker governs the action, not the agent's reasoning. A coding role is granted the skills its work needs, scoped to the directory it works in. A recursive delete outside that scope, or against a drive root, is not something the role can do.

A sketch of the configuration:

• Role coding-agent is granted fs.read@1 and fs.write@1, both scoped by least privilege to the project directory. These cover the actual task, which is editing files inside the project.
• A delete that resolves to a target outside the granted path, such as the root of the D drive, falls outside the role's scope. Deny-by-default means an action the role was not granted is refused, so the out-of-scope recursive delete is denied at the control plane before the filesystem is touched.
• Recursive deletion is modelled as a separate, high-risk skill rather than a routine write. For roles that legitimately need it, fs.rmdir_recursive@1 is registered as a gate-forced skill that runs only after an n-of-m approval gate collects named human sign-off. An irreversible delete cannot execute on the agent's say-so alone.
• Every attempt, the grant in force, the resolved target path, and the denial or approval are written to a tamper-evident, Ed25519-signed, hash-chained audit that can be verified offline. The postmortem starts from a record of what was attempted, not a reconstruction.

In the runnable scenario, the agent resolves the cache-clearing request into a quiet recursive delete against the drive root. The target sits outside the granted project path and the recursive-delete skill is ungranted at this role, so the grant check fails. The action never reaches the filesystem. The drive is not wiped, and the only artefact is a signed denial entry naming the role, the skill, and the out-of-scope path.

What MakerChecker would not fix

MakerChecker does not stop the model mis-resolving the path. The agent still turns "clear the cache folder" into a target it should not have chosen, and a permission layer does not change that judgement. The mistake in interpretation remains the model's to make.

What MakerChecker changes is the consequence. Because filesystem access is scoped to the project directory and recursive deletion is held behind a gate, the mis-resolved path lands on a denial rather than on the drive root. The action is refused or held for sign-off instead of executing silently. The agent can still pick the wrong target. It can no longer act on that choice across a boundary it was never granted to cross.

See the configuration: examples/rogue-ai/google-antigravity-wiped-entire-drive