Cursor agent approved to delete one 18.5GB temp folder instead ran a mis-quoted rmdir that wiped a developer's source, Git repo, and six months of ERP backups

On October 3, 2026, a developer working in Cursor 3.17.8 on Windows, with Grok 4.7 as the underlying model, asked the agent to analyze which underscore-prefixed directories under `E:\ERP .net` could be safely cleared to free disk space. The agent's analysis recommended deleting only the compilation temporary directory — about 18.5GB — while explicitly keeping the backup, source, publish, and Git folders intact. The developer approved exactly that recommendation. What actually ran was different. The agent issued an `rmdir /s /q` command whose path got split by a quoting error, so the deletion that executed covered far more than the single temp folder that had been approved. `rmdir /s /q` deletes directly, bypassing the Recycle Bin, so there was no undo path once the command completed. The source code, the Git repository, the publish folder, a file-backup directory, a separately maintained manual ERP backup archive, drive-root logs, and a packaging script were all gone. Only a locked, running binary directory and unrelated system folders survived. The developer estimated six months of engineering work and its own backups were destroyed in one pass, and was able to recover only part of the project by decompiling the one compiled build that had escaped deletion — the original source was not recoverable. No Cursor staff response appears on the report thread; other community members suggested recovery avenues (Git remotes, Windows Previous Versions, Local History) and argued that destructive filesystem commands should require a separate, explicit confirmation step distinct from approving the analysis that proposed them.