Cursor Grok 4.7 wiped all data on secondary drive

[Lukas_Korsakas]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Grok 4.7 in agent mode caused a wipe in my secondary drive. A quoting bug caused rmdir to run against the drive root.

Steps to Reproduce

Don’t have any idea

Expected Behavior

It should not completely wipe all my data on disk drive

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.17.8 (user setup)
VS Code Extension API: 1.128.0
Commit: 2fdd31c9f33f7fbe501f2d57772dc5bf64b63620
Date: 2026-08-20T02:18:12.724Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Grok 4.7

For AI issues: add Request ID with privacy disabled

289d567e-3d56-488b-972d-a46e0b76a98b

Additional Information

Agent mode, model Grok 4.7, OS Windows 10.0.26200, shell PowerShell.
The user did not type this command. The agent issued a Shell tool call with required_permissions: [“all”] (sandbox disabled).

Intent: delete only this scratch folder the agent had created:
D:\Cursor projects\Logicmachine bacnet GA_lm_backup_20261013

Two correctly scoped Remove-Item calls failed because the folder was in use (shell cwd was inside it).

The third call was recorded as:
cmd /c "rmdir /s /q “D:\Cursor projects\Logicmachine bacnet GA_lm_backup_20261013"”
cwd: D:\Cursor projects\Logicmachine bacnet GA
started: 2026-10-13T08:08:11.962Z
ended: 2026-10-13T08:09:01.518Z
pid: 81380
exit: 4294967295 (agent then ran Stop-Process -Id 81380 -Force)

The nested quotes did not survive PowerShell into cmd. rmdir /s /q ran against “” (D:), not the scratch folder. /s /q deletes recursively, prints nothing on success, and does not use the Recycle Bin.

Terminal log only shows failures. Refused with “Access is denied”: $Recycle.Bin, $Windows.~WS, $WINRE~1, .GamingRoot, Autodesk installer tree, Config.Msi, hiberfil.sys, Intel folders, and other root items. “\CURSOR~1\LOGICM~1” (D:\Cursor projects\Logicmachine bacnet GA) returned “being used by another process”. rmdir /s deletes children first, so the locked directory remained and its contents were removed.

Confirmed after the kill: that project folder had 0 files and no .git (timestamp 2026-10-13 11:08:26 local). Sibling folders under D:\Cursor projects were gone. The project had about 967 files before this. Successful deletes are absent from the log, and there was no pre-image of D:, so the log is not a full damage list. A later attempt to list D:\ was blocked by auto-review. Get-CimInstance Win32_ShadowCopy failed with HRESULT 0x80041014.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed report. I’m really sorry this happened. Losing data is always painful.

Your analysis sounds right: when the command was passed from PowerShell into cmd /c, the nested quotes \" were not preserved as escapes, so rmdir /s /q ran on the root of D:\ instead of the target folder. You were using Auto-review, and it should have stopped a recursive command like that and asked first. It should not have gone through without confirmation, and this was not caused by your settings. I’ve passed the details to the team.

Right now, the most important thing is recovery:

• Stop all writes to D: right away. Don’t install, save, or copy anything there, since new writes can overwrite deleted data.
• Run a recovery tool from C:, and save the recovered files to another drive: Microsoft Windows File Recovery winfr or PhotoRec.
• If D: is an SSD with TRIM, the chances of recovery are lower.
• Anything that was pushed to a git remote can be cloned again.

For now, until this is fixed, I’d suggest switching run mode to Ask Every Time in Cursor Settings > Agents > Run Mode. Then every terminal command will wait for your click before it runs.

I’ll post here if there’s an update.