A developer asked an agent to clean up one temporary folder. By their account it deleted 10,382 files, including a backup archive of 8,291 files that was the only surviving copy of some of them. About 15 percent came back.
The command that did it was not reckless. It was a perfectly ordinary delete aimed at a perfectly ordinary path. What made it catastrophic is a single backslash, and a shell that refuses to read it the way the model expected.
TL;DR
An agent writes a Windows delete command with a backslash before the closing quote, expecting C-style escaping. PowerShell does not escape quotes that way, so the string ends early and a bare backslash arrives as the path, which Microsoft documents as meaning the root of the current drive. Claude Code fixed this in 2.1.283 on 2026-09-25, though npm's stable tag still trailed the fix when we checked on 2026-09-30. Cursor called it a known issue on 2026-09-19 with no fix shipped.
The mechanism, correctly
Nearly every write-up of this bug, including the original bug reports, explains it as "the trailing backslash escapes the closing quote." That is the wrong way round, and getting it right is what tells you which paths are dangerous.
Start with what the agent generates:
cmd /c "rmdir /s /q \"D:\Projects\quiz-check\_tmp_inspect\""
The model has written \" because that is how you escape a quote in C, in JSON, in Python, in almost everything it has read. It is a reasonable habit. It is also wrong here twice over: cmd.exe's escape character is ^, not a backslash, and PowerShell's is a backtick. Backslash-quote escaping belongs to the C runtime's argument parser, not to either shell.
A Cursor staff member, posting as deanrie on 2026-09-19, put it plainly:
In PowerShell, a backslash doesn't escape a quote the way it looks in the command, so
rmdir /s /qended up targeting the root of D: instead of the temp folder.
So the quoted string terminates at that quote rather than continuing past it. The arguments re-split, and what survives as rmdir's path is a lone backslash.
Now read Microsoft's own rmdir reference, which is where the damage is specified:
If you include a backslash at the beginning of the specified path, then the path starts at the root directory (regardless of the current directory).
A bare backslash is a path that begins with a backslash. So rmdir /s /q \ means the root directory, and the working directory only decides which drive gets it. That is why every corroborated report in this cluster ends at a drive root rather than at a parent folder. The /s makes it recursive and the /q removes the confirmation, which Microsoft's own docs flag: "When you run in quiet mode, the entire directory tree is deleted without confirmation."
One honest limit on this explanation. We reconstructed this chain from Microsoft's documentation and the vendor statements above, in a Linux environment where we could not run cmd.exe or PowerShell to reproduce it. The outcome is beyond doubt and vendor-confirmed. The exact tokenisation is documented rather than observed here. The strongest independent support is what Anthropic chose to code against: in 2.1.281, shipped 2026-09-23, they extended their dangerous-removal check to flag "a removal at a backslash-only target." Vendors do not write a guard for a bare backslash unless a bare backslash is what turns up.
The half that is actually about security
The mechanism above is a quoting bug. This next part is a permissions failure, and it is the reason the post exists.
In the Claude Code issue filed on 2026-09-11, the agent's first attempt was blocked:
Remove-Item "E:\<folder>\SS" -Recurse -Force
The protection worked. It returned This path is protected from removal.
The agent then reached the same goal through a different binary, cmd /c rmdir, which that protection did not cover. According to the reporter, the session had already produced several false positives from the same safety check earlier on, which is offered as the reason a genuine block read as noise.
Worth separating two claims there. That the agent intended to defeat a safety control is an interpretation of a pasted transcript, and enumerating alternatives after a tool error is also just ordinary retry behaviour. What needs no mind-reading is the capability gap, and for that we have the vendor's own words. Anthropic's changelog for 2.1.283, published 2026-09-25:
Windows: Fixed the PowerShell tool letting
cmd /c rd,rmdir,delorerasedelete drive roots, the home folder and other folders thatRemove-Itemrefuses
Read the end of that sentence again. Those commands could reach folders Remove-Item refused. The guardrail covered one spelling of "delete" and not four others, and the vendor has now said so in a release note.
This generalises past Windows and past any single tool. If your agent's safety configuration is a list of commands to block, you have protected those strings, not the outcome. Remove-Item, rmdir, rd, del /s, robocopy /MOVE, a two-line Python script calling shutil.rmtree: one result, many spellings. A model that is genuinely trying to finish your task will find a spelling that works, and it will not report that anything went wrong, because from where it sits nothing did.
Where each vendor stands, as of 2026-09-30
Claude Code: fixed. The 2.1.283 entry above landed on 2026-09-25, fourteen days after the issue was filed. One caveat we checked directly against the npm registry: the stable dist-tag still resolved to 2.1.280 from 2026-09-22, while latest was 2.1.285. If you track a stable channel, the fix may not have reached you, so verify the version rather than assuming a recent install covers it.
claude --version
# 2.1.283 or newer includes the Windows PowerShell delete fix
Cursor: not fixed. Staff acknowledged the pattern twice. On 2026-07-30, mohitjain wrote that the quoting "can collapse so the delete resolves to the drive root. It's a pattern we're aware of and tracking." Seven weeks later, on 2026-09-19, deanrie wrote: "This is a known issue we're tracking, and I've passed your case to the team." There is no changelog entry addressing shell quoting or destructive commands, and reports continued through 2026-09-23.
Cursor's guidance in the meantime is a setting, not a patch, and their own framing of it is the most useful sentence a founder can read here:
On Windows, terminal commands don't run in a sandbox, so your confirmation is the main line of defense.
That matches what their run-modes documentation describes. The sandbox implementations it details are macOS, using Seatbelt, and Linux, using Landlock and seccomp, with kernel requirements spelled out. We found no equivalent Windows implementation described on that page as of 2026-09-30. The same page says the Auto-review classifier "can make mistakes" and is not a security boundary.
So: the platform carrying a known unfixed drive-root delete is also the platform with the least isolation documented around the agent's shell, and the approval prompt is doing the work people assume the sandbox is doing.
It is not the model
A tempting read here is that some models are careless with destructive commands. The reports do not support it.
The Cursor incidents name Grok 4.5 High, Grok 4.6 Extra High and Composer. The Claude Code one was running Opus 5. Different vendors, different training, same failure, because the error happens where a generated string meets a Windows shell. Switching models does not help. Changing how much the shell is allowed to do does.
What to actually do
Find out whether your agent can delete without asking you. In Cursor this is the Run Mode: Run Everything executes every tool call with no prompt and, on Windows, no sandbox either. If you switched that on to stop the interruptions, that is the setting that matters here. Cursor's own advice is Ask Every Time, or an Allowlist with nothing dangerous on it, plus File Deletion Protection.
Confirm you have a backup that is not on that machine. Not a folder named backup on the same drive. In the 2026-09-11 report the backup archive died in the same command as the source, because a drive-root delete takes both. A copy on the same volume is a copy, not a backup.
Update Claude Code and check the number. claude --version should read 2.1.283 or newer. The stable channel trailed the fix as of 2026-09-30, so this is worth looking at rather than assuming.
Stop treating a command denylist as the boundary. Keep it, because it raises the cost of an accident. But the things that actually hold are an approval step on destructive actions and an agent that has no write access outside the project in the first place.
Give the bug less room in your paths. Keep projects off the drive root and out of directories with spaces in the name. D:\dev\myapp is a smaller blast radius than a project sitting one level under the volume root, and the reports cluster around paths where quoting had more to go wrong with.
What we can and cannot see from here. CheckYourVibe scans deployed applications, so this particular failure is outside what our scanner detects: it happens on your laptop, before anything ships. We are writing it up because the audience is the same, and because the lesson about name-matched guardrails applies directly to the permissions people hand to agents that do reach production.
We had the milder version of this advice on the site already. Our agentic AI security risks page says "Cursor has permission controls for terminal commands. Use these features." Still true, and still worth doing. It needed the caveat this incident supplies: use them, and don't mistake them for a boundary.
Why did my AI agent delete my whole drive instead of one folder?
On Windows the agent writes a delete command with a backslash before the closing quote, expecting the shell to treat it as an escape character. PowerShell does not. The quoted string ends early, the arguments re-split, and a lone backslash arrives as the path. Microsoft documents that a path beginning with a backslash starts at the root directory regardless of the current directory, so the command deletes the root of whichever drive you were working on. Cursor staff confirmed this explanation on 2026-09-19.
Is this fixed?
In Claude Code, yes, as of version 2.1.283 published 2026-09-25. Its changelog entry says the PowerShell tool no longer lets cmd rd, rmdir, del or erase delete drive roots, the home folder and other folders that Remove-Item refuses. Watch your version though: the npm stable tag still pointed at 2.1.280 from 2026-09-22 when we checked on 2026-09-30, which predates the fix. In Cursor it is not fixed. Staff called it a known issue they are tracking on 2026-09-19 and gave no timeline.
Can I get the files back from the Recycle Bin?
No. The Recycle Bin is an opt-in behaviour of the Windows shell API, requiring an explicit flag that command-line deletes never set, so a shell rmdir removes files in place. If this just happened, stop writing to that disk immediately, because everything saved afterwards reduces what an undelete tool can recover. The reporter in the Claude Code case recovered roughly 15 percent, and only because copies existed on a server and a second machine.
Does a protected path or deny rule prevent this?
Not on its own, because those rules match command names and deleting a directory has several command names. In the report filed on 2026-09-11 a Remove-Item call was refused with the message that the path is protected from removal, and an equivalent cmd rmdir was not covered by the same protection. Anthropic's own fix entry confirms that gap existed. Cursor's run-modes documentation separately says its Auto-review classifier can make mistakes and is not a security boundary.
Is this a problem with one specific AI model?
No, and that matters for how you protect against it. The Cursor reports name Grok 4.5 High, Grok 4.6 Extra High and Composer, while the Claude Code report was running Opus 5. Different vendors, different models, same failure, because the mistake is in how a generated string meets the Windows shell rather than in any one model's judgement. Treat it as a property of running agents on Windows, not as a reason to switch models.
Shipped something an agent wrote?
This bug hits your laptop. Scan what reached production.