Windows Agent rmdir broken quoting wiped D: - ticket T-F90960 (Grok 4.6 Extra High)

[Mohamed_Sedawy]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On 17 Sep 2026 ~14:49 local, Cursor Agent executed a cleanup rmdir meant to delete only a temp folder. Broken Windows cmd quoting collapsed the path so rmdir /s /q also targeted , i.e. D: drive root. Most of D: was permanently deleted (no Recycle Bin).

Support ticket: T-F90960
Billing confirmed Agent-executed rmdir with broken quoting, logged product/safety, and handed off to the technical team. Compensation closed under ToS — this report is for product correlation only.

Same failure mode as:

Cursor Deleted my D Drive

Where does the bug appear (feature/product)? Cursor IDE Describe the Bug Cursor deleted the majority of my D drive which included all of my project files in spite of having File-Delection Protection and External-File Protection turned on. Steps to Reproduce I’m not sure and I don’t want to FAFO anymore. Expected Behavior To adhere to the system settings and not delete my D drive. Operating System Windows 10/11 Version Information Version: 2.4.21 (user setup) VSCode Version: 1.105.1 Commit…

Composer / chat ID: a58e63ab-20cb-4a4d-a6ab-d9e9e2ae4c8c

Steps to Reproduce

1. Agent (Grok 4.6 Extra High) created a temp folder under the open project on D:.
2. Agent ran Shell cleanup via nested cmd quoting, intended only for that folder.
3. Quoting broke; rmdir received a second target of \ (drive root).
4. rmdir /s /q \ recursively deleted unlocked contents of D:.

Exact command from Agent transcript:
cmd /c “rmdir /s /q "d:\Projects\1_Freelancer\49 - Build a 360 Camera with Raspberry PI 5\New Project_aio_spec_pages"”

Expected Behavior

• Nested cmd /c + rmdir quoting must not collapse a folder path into drive root .
• Recursive deletes must not auto-run without hard confirmation.
• Path resolution should refuse/halt if the effective target is a drive root.
• File-Deletion / External-File Protection should cover destructive terminal deletes, or Agent must not use unprotected shell deletes for cleanup.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Cursor Desktop on Windows 11 (10.0.26200), incident date 17 Sep 2026. Exact About build string available on request.

For AI issues: which model did you use?

Grok 4.6 Extra High

For AI issues: add Request ID with privacy disabled

Privacy Mode stays ON (client work — cannot disable).

Request ID I was able to copy without changing privacy:
f9a7046a-279b-47e5-ab48-6e8dc12daba1

Composer / chat ID (local transcript; enough for correlation with T-F90960):
a58e63ab-20cb-4a4d-a6ab-d9e9e2ae4c8c

Additional Request IDs from local logs on the same composer (18 Sep):
5ae5f477-122b-4223-b38c-4f4a63779ebc
dd0b0927-db48-4710-a359-74a8dfc2641e

If engineering needs a Privacy-Mode-off Request ID from the wipe turn (~14:49 on 17 Sep 2026), correlate via ticket T-F90960 + composer ID above. I will not disable Privacy Mode.

Additional Information

Screenshots of the Agent command and emptied D: are on ticket T-F90960.
Impact: most of D: wiped; on-disk recovery only partial after overwrites.
Related: Serious data loss after Cursor Agent mis-executed rmdir /s /q on Windows — seeking awareness and support

Cannot disable Privacy Mode (client confidentiality). Correlation via T-F90960 + composer ID + screenshots already on the ticket.

After the wipe, an Agent admin restore briefly started copying C: onto D: (overwriting free space) before it was stopped. Screenshot available on request / on ticket T-F90960.

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey @Mohamed_Sedawy. Thanks for the detailed report, and I’m sorry about the data loss on D: That’s always painful.

You don’t need to disable Privacy Mode. Using the composer ID and support ticket T-F90960, we were able to correlate the incident. I can see the agent post-mortem screenshots, and what you described matches the mechanism we’re tracking. In PowerShell, a backslash doesn’t escape a quote the way it looks in the command, so rmdir /s /q ended up targeting the root of D: instead of the temp folder. This is a known issue we’re tracking, and I’ve passed your case to the team. The models are continuously being trained to handle destructive operations more carefully, and that work is ongoing.

One question that would help the team: what run mode was the Agent in at the time? You can see it in Cursor Settings > Agents (Auto-Review, Run Everything, Allowlist, or Ask Every Time). Also, do you remember whether an approval request popped up for that cleanup command, or did it run on its own?

For ongoing work in Cursor on Windows, these two settings provide the strongest protection:

• Run mode = Ask Every Time (or Allowlist with an empty list), so every terminal command waits for your confirmation.
• Enable File Deletion Protection in the Agent settings.

On Windows, terminal commands don’t run in a sandbox, so your confirmation is the main line of defense.

On recovery, your agent’s advice was correct. Don’t write anything else to D:, and run a recovery tool from another drive, restoring to another drive as well. I understand it may already be too late in your case, but I’m leaving this here in case someone else reads the thread.