How a Cursor cache cleanup reportedly deleted 300GB on Windows
Cursor7 min readBusiness + PersonalA Cursor cache-cleanup request reportedly expanded beyond the project, deleting about 300GB of work and personal files and damaging Windows.
“Clear the cache” sounds harmless because people think about the category of files, not the command that implements it. An agent must translate that goal into paths, shells, flags, and a target set. If one quote or variable collapses, the operation can move from a disposable cache to the root of a drive.
How the incident unfolded
The public account dates the incident to May 8, 2026. The report centers on a Cursor forum user, using Cursor IDE on Windows.
The intended scope was Expo, Android, Gradle, npm, node_modules, and build cache data. The agent generated a quiet recursive directory deletion through the terminal.
Incorrect quoting or path handling widened the resolved target beyond the project. The quiet flag removed the operating system's final interactive confirmation.
Recovery advice came only after the broad deletion had completed. The reporter described hundreds of gigabytes of projects, business data, and personal files gone in seconds, plus partial Windows damage. A forum response characterized PowerShell-to-cmd quoting with rmdir /s /q and root-resolving paths as a known Windows failure class.
What actually caused the damage
The agent did not need a special way into the computer. It used the same terminal access the person had already granted. Once a command was allowed to run with that access, folders outside the visible project were reachable too.
Opening one project in an agent does not automatically fence the agent inside that folder. A real boundary has to be enforced before a command runs, especially when the command can remove many files at once.
Intent describes a file class; the shell acts on resolved paths. Security has to inspect the latter.
A recursive operation is multiplicative: one wrong ancestor can convert a small cleanup into hundreds of gigabytes of loss.
Auto-run and command allowlists reduce friction, but a previous permission to clean a cache should never become permission to delete an unknown target set.
A more accurate Cursor IDE on Windows model might make fewer mistakes. It still cannot replace limits on what the software is allowed to do.
How Leash could have changed the outcome
With a supported Cursor IDE on Windows integration, Leash checks the proposed action before it runs. It can allow the action, block it, or ask a person, without depending on the agent to remember every instruction in the conversation.
Destructive Protection can recognize a broad or recursive deletion, while Rules Protection can protect personal folders and anything outside the active project.
Leash evaluates Cursor shell execution before the terminal receives it. A Personal user can set broad filesystem actions to Ask or Block; a chosen rule can make drive roots and paths outside the project non-negotiable.
The decision should be about the resolved consequence: recursive deletion, target root, and cross-project reach—not the reassuring phrase “cache cleanup.”
If the command cannot be explained safely, denial is cheap. The agent can switch to a dry run, enumerate exact cache paths, or ask the user to clean them manually.
For a Cursor forum user, that would mean ordinary work could continue while the exact dangerous step received its own decision. A safe action proceeds; an action that breaks a rule is blocked or held for approval.
Leash would not need to predict every choice made by Cursor IDE on Windows. It would only need to stop the dangerous action before it became real.
What this means for a new agent user or indie developer
For a newcomer or indie developer, the practical lesson is simple: an open project is not a sandbox. If an agent can use your terminal, assume it can reach every file your account can reach until a real rule proves otherwise.
A sensible starting policy for this case is: Require a dry run and target count before recursive cleanup. Never authorize a drive root, home directory, or project ancestor through a reusable allowlist.
Leash Personal Open Source can protect a Cursor IDE on Windows workflow locally with your own model-provider key. Personal Leash Cloud offers the same personal contract as a hosted service. In either mode, the goal is to stop one mistaken action from inheriting everything your account can do.
What a CIO, CTO, or CISO should take from this
For a CIO, CTO, or CISO, agent terminal access should be treated like automation running under an employee's identity. Project boundaries, protected user folders, recoverable deletion, and evidence of every high-impact decision matter more than which model produced the command.
For organizations using Cursor IDE on Windows, Business Leash Cloud adds an independent action-time safety layer. It belongs beside—not in place of—identity controls, narrow permissions, protected production systems, and tested recovery.
For this incident, the operational priorities are clear: Prefer tool-specific cache commands over generic recursive deletion. Back up irreplaceable work to a destination outside the agent's deletion authority.
What to change before the next agent session
For this file-loss case, start with the consequences that would be hardest to reverse. Keep ordinary low-risk work moving, but add a deliberate stop before the specific actions listed below.
- Require a dry run and target count before recursive cleanup.
- Never authorize a drive root, home directory, or project ancestor through a reusable allowlist.
- Prefer tool-specific cache commands over generic recursive deletion.
- Back up irreplaceable work to a destination outside the agent's deletion authority.
What is confirmed—and what is not
This account follows Cursor forum: 300GB cache-cleanup data-loss report and the additional sources linked below. Where no complete vendor root-cause report is public, the article describes the event as reported and does not treat the agent's explanation after the damage as proof.
The public report does not expose a complete command transcript. The prevention path therefore relies on the proposed recursive shell action being visible to Cursor's before-execution hook and a Leash rule covering Windows recursive delete syntax and out-of-scope paths.
The Leash claim for Cursor IDE on Windows has a clear boundary: the action must pass through a supported before-action integration. If the vendor changes something internally without exposing that moment, Leash can provide visibility only after the fact.
The bottom line
The lasting lesson is not that agents should never clean files. It is that a cleanup request should never silently become permission to erase unrelated parts of a computer.
The point is to keep Cursor IDE on Windows useful for routine work without gambling the wider laptop, repository, inbox, or production environment. That is the practical role Leash is designed to play in this story.