The chat agent ran a bulk file rename using bash-only BASH_REMATCH in zsh. Capture groups were empty, so every file was renamed to the same name. Each mv overwrote the previous file. About 883 ToBeNamed_*.jpg files were reduced to one file (~50 KB). About 250 other files in the same folder were not touched per instruction. Irreversible local data loss.
Steps to Reproduce
Open Cursor IDE chat/agent on macOS (zsh shell).
Ask the agent to bulk-rename many files matching [old].jpg to [new].jpg in a local folder (hundreds of files).
Ask it to leave other files unchanged.
Let the agent run a shell loop that uses BASH_REMATCH to build target filenames.
Observe: all sources collapse to a single destination filename; only the last rename’s bytes rema
Expected Behavior
Each file gets a unique new name preserving bag number and sequence (e.g. [old]_0001.jpg → [new]_0001.jpg) No overwrites. Non-matching files unchanged. Agent should use a shell-safe rename (or explicit bash), verify counts before/after, and not run a destructive bulk rename without checking that targets are unique.
Operating System
MacOS
Version Information
Cursor IDE 3.4.20
For AI issues: which model did you use?
Auto
For AI issues: add Request ID with privacy disabled
900f2821-85d3-4189-ab38-245f70b665d4
Additional Information
Severity: critical — mass accidental deletion via overwrite, not a single-file mistake.
No full paths posted intentionally; Request ID should link the session internally.
Agent did not validate rename results (file count, duplicate targets, or shell compatibility) before/after.
User attempted Time Machine / local recovery afterward; no local APFS snapshots found at time of incident.
This was a straightforward rename task; failure mode was entirely from the generated shell script, not from ambiguous user intent.
Hey, I’m sorry, losing 883 files due to an overwrite is a really painful scenario, especially if you don’t have a backup handy.
A few recovery ideas before we close this out:
iCloud Photos or any cloud sync like Dropbox, Google Drive, OneDrive. If the folder was ever synced, check version history, deleted items, or historic versions within the 30-day window. Many services keep older versions of overwritten files.
Originals. If the JPEGs came from a camera, phone, or SD card, the originals might still be on the source device.
Data recovery tools like Disk Drill, PhotoRec, R-Studio. mv within the same filesystem is basically an inode rename, so the original blocks might not have been overwritten yet if that space hasn’t been reused. Odds are medium, but it’s worth trying before anything writes new data to the disk. The sooner you stop writes to that volume, the better.
APFS snapshots. You said you already checked, but just in case run tmutil listlocalsnapshots / in Terminal, there might be something besides Time Machine.
About the incident itself, models are being trained to be more careful with destructive shell operations and to validate results like counts and unique targets. This is an active area of work. A few practices that really reduce the chance of this happening again:
Don’t auto-run destructive commands. Bulk mv or rm in a loop should always be reviewed before you approve it, especially if the script uses regex or parameter expansion. It’s easy to mess up shell specifics like BASH_REMATCH vs zsh.
Do a dry run first. Ask the agent to print echo mv "$src" "$dst" for the full list without running it, check destination uniqueness, then run the real command. Takes a few seconds and prevents exactly this.
Make a snapshot or backup before big batch operations. cp -R folder folder.bak or git init plus a commit in the folder, even if it’s not code. Cheap and it saves you.
Use Plan mode for unfamiliar tasks. Keep in mind that in Plan mode, shell commands are currently only restricted by the system prompt, not a harness, so you still need to review.
I noted the Request ID, thanks for including it, it helps us investigate cases like this on our side.