Agent ran destructive delete script on dev vault without warning

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Agent wrote and executed a Node.js packaging script that recursively deleted my personal Obsidian vault folder without warning or explicit consent.

I asked the Agent to rename two GitHub repos and create a GitHub Release zip that extracts as “Light Life”. The Agent ran:

node “+/scripts/package-starter-release.mjs” --source ../light-life-starter --zip --version v0.1.0

The script’s default output path was my live dev vault folder (../Light Life — same path I work in daily). Before copying starter files, it ran:

fs.rmSync(outDir, { recursive: true, force: true })

This wiped my entire vault: .git, daily notes, projects, inbox captures, area tasks, and personalization files.

The Agent did not explain that the command would delete my folder. I would have refused if I had known.

After the wipe, the Agent “restored” by cloning my private GitHub repo (light-life-own). That repo only contained the initial system scaffold — personal content was intentionally gitignored and had never been pushed. The restore looked successful but personal data was gone.

Impact: permanent loss of local-only personal vault data (projects, tasks, dailies, inbox) unless recoverable from Google Drive version history.

Steps to Reproduce

  1. Open Cursor IDE Agent mode on a real project with personal/local-only data (e.g. Obsidian vault with .gitignore excluding user content folders).

  2. Ask the Agent to create a “release zip” or package a distribution build from a sibling output folder.

  3. Let the Agent write a script that:

    • defaults --out to the live working directory (or a folder with the same name as the dev vault)
    • calls fs.rmSync(outDir, { recursive: true }) before copying

  4. Agent runs the script without:

    • explaining the delete step
    • asking for confirmation
    • passing an explicit safe --out path

  5. Observe: the live vault folder is deleted and replaced with sanitized distribution content.

  6. (Optional) Agent attempts recovery by git clone — fails to restore gitignored personal files.

Reproducible pattern: Agent + destructive rmSync + default output = live user folder + no user confirmation.

Expected Behavior

  1. The Agent should NOT run destructive filesystem operations (recursive delete, rm -rf, fs.rmSync on user directories) without:

    • clearly stating what will be deleted
    • requiring explicit user approval (“yes, delete folder X”)

  2. Scripts the Agent writes should:

    • never default output to the operator’s live working directory
    • refuse to delete paths that look like active dev vaults (contain .git, user content folders, etc.)
    • require a --confirm-delete flag before overwriting an existing directory

  3. If data loss occurs, the Agent should NOT assume git clone is a valid restore when .gitignore excludes personal data — and should warn the user before replacing the folder.

  4. For packaging/release tasks, the Agent should use an isolated output path (e.g. _release-pack/) and treat the live vault as read-only.

Operating System

Windows 10/11

Version Information

Version: 3.11.13 (user setup)
VS Code Extension API: 1.125.0
Commit: 3f21b08f0b436a07be29fbfe00b304fa15553350
Date: 2026-07-10T01:45:28.254Z
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.256
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Auto

For AI issues: add Request ID with privacy disabled

35cbd442-fab8-4bd8-82c5-af753cfdab52

Additional Information

Project context:

  • Personal Obsidian vault at: C:\Users-—\Obsidian\Light Life
  • Distribution sibling: light-life-starter
  • Script involved: +/scripts/package-starter-release.mjs (written by Agent in prior session)
    Dangerous code pattern (Agent-authored):
  • Default outDir resolved to ../Light Life (operator dev vault)
  • fs.rmSync(outDir, { recursive: true, force: true }) before copy
    Recovery attempt made things worse:
  • Agent renamed overwritten folder to Light-Life-packaged-starter-backup
  • Agent ran: git clone https://github.com/-----light-life-own.git “Light Life”
  • GitHub repo had only 1 commit (system scaffold); personal data was .gitignore’d locally
    Data lost (local-only, not on GitHub):
  • 01 Daily/, 02 Inbox/, 03 Projects/, 04 Areas/ tasks, 05 Knowledge/, personalization/
    User had NOT consented to folder deletion — only agreed to repo rename and release zip.
    Suggested product fixes:
  1. Agent policy: block or require approval for rmSync / rm -rf / recursive delete on workspace paths
  2. Agent should surface “THIS WILL DELETE …” before running destructive shell commands
  3. Safer defaults for any script that writes output directories
    I have since patched the script locally with path guards (safe-output-path.mjs), but the Agent behavior issue remains.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey Johan. I’m really sorry, losing a local vault is brutal, especially when it had daily notes and projects that weren’t backed up.

First, recovery steps while the data might still be salvageable:

  • If the folder was synced with Google Drive, OneDrive, or Dropbox, check the version history in the web UI. That’s usually the most reliable way to recover local-only data.
  • On Windows, stop writing anything to that disk and try file recovery tools like Recuva or PhotoRec. On an SSD with TRIM the odds are lower, but it’s still worth a try.
  • git clone won’t bring back .gitignored content. You’re right that the repo only had the scaffold.

Now the main point. The destructive part (fs.rmSync) was hidden inside a script the Agent wrote and then ran via node. This is a known limitation. The current delete checks look for recognizable file operations and shell commands, but they don’t inspect logic inside an executable script, so destructive actions hidden inside a node or python script won’t be caught. The team is working on more reliable approaches, but this isn’t a one-off bug, it’s something that gets improved iteratively. I reported this exact scenario internally. I can’t share a specific timeline for a fix.

What I’d recommend going forward to reduce risk:

  • Keep Auto-Run on Auto-review or Allowlist, not Run Everything. Important note: even with delete protection, destructive code hidden inside an executable script (node or python) won’t be intercepted right now, so treat Agent-generated scripts as untrusted and review them before running.
  • Enable File-Deletion Protection and External-File Protection in the Agent settings.
  • Never point build or release output at a live data directory. Use an isolated path like _release-pack/.
  • Keep personal or local-only data under version control or in regular backups.

It’s good that you already added path guards to the script. Let me know if any recovery option works or if you want help.