Agent parallel subagents overwrite dirty worktree / destructive git recovery wastes tokens

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agent parallel subagents overwrite dirty worktree / destructive git recovery wastes tokens

Where does the bug appear (feature/product)?

Cursor Agent / Project Agent / Task subagents (Composer Agent)

Describe the Bug

During a multi-slice “god-class deepen” refactor, the agent spawned parallel write-capable subagents in the same working tree. Their overlapping edits overwrote each other. Recovery paths then used destructive git operations (git reset --hard / git clean-style cleanup were reported), which wiped uncommitted prior work and project AI policy files that had never been committed.

The agent continued re-implementing lost work without first stopping to ask for a checkpoint commit/stash/branch. That burned a large amount of AI tokens and user time, and left the repo in a partially reconstructed state.

Related known class of issues:

Steps to Reproduce

  1. Start with a dirty git worktree (substantial uncommitted changes).
  2. Ask Agent/Project Agent to implement a multi-slice refactor plan (“don’t stop until all todos complete”).
  3. Observe the orchestrator spawn multiple write-capable Task subagents in parallel with overlapping file scopes.
  4. Observe file overwrites / slice re-application; in worse cases, destructive git recovery clears local changes.
  5. Agent continues regenerating lost work instead of stopping to ask the user to commit/stash first.

Expected Behavior

  1. Before large multi-file work on a dirty tree: stop and ask commit / stash / branch / proceed.
  2. Never run git reset --hard, git clean, unrelated git restore, or git stash -u without explicit user approval listing affected paths.
  3. Parallel subagents must have disjoint write scopes; if overlap is uncertain, sequence the work.
  4. If files disappear mid-session: stop, report loss, ask how to recover — do not silently redo and burn tokens.

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

(please paste from Help → About)

Additional Information

  • Repo: local Java desktop app (price-checker), long Agent session with Phase 6 god-class deepen plan.
  • Impact: uncommitted feature/policy work lost; jSparrow/platform policy pack wiped; large token waste redoing slices.
  • Product ask: hard safety rails in Agent/Project orchestration for dirty trees + parallel writers + destructive git, independent of project rules (rules alone were not enough).

Does this stop you from using Cursor

No — but it causes severe data loss risk and token waste on large Agent refactors.

Steps to Reproduce

Steps to Reproduce

  1. Start with a dirty git worktree (substantial uncommitted changes).
  2. Ask Agent/Project Agent to implement a multi-slice refactor plan (“don’t stop until all todos complete”).
  3. Observe the orchestrator spawn multiple write-capable Task subagents in parallel with overlapping file scopes.
  4. Observe file overwrites / slice re-application; in worse cases, destructive git recovery clears local changes.
  5. Agent continues regenerating lost work instead of stopping to ask the user to commit/stash first.

Expected Behavior

Expected Behavior

  1. Before large multi-file work on a dirty tree: stop and ask commit / stash / branch / proceed.
  2. Never run git reset --hard, git clean, unrelated git restore, or git stash -u without explicit user approval listing affected paths.
  3. Parallel subagents must have disjoint write scopes; if overlap is uncertain, sequence the work.
  4. If files disappear mid-session: stop, report loss, ask how to recover — do not silently redo and burn tokens.

Screenshots / Screen Recordings

cursor_defect_pic.jpg
cursor_defect_pic.jpg1920×1032 399 KB

Operating System

Windows 10/11

Version Information

Version: 3.13.10 (user setup)
VS Code Extension API: 1.128.0
Commit: 4f02290ccd9304f0e6bf8ee85f6e9106f02ac1f0
Date: 2026-07-23T21:41:07.333Z
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?

Cursor Grok 4.5 High Fast

Additional Information

This process would be easier if you created a MCP server plugin so I can have AI create the defect for me.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Thanks for the detailed report, @James_Prejsnar, and sorry about the lost work.

Recovery first (try soon, before more changes overwrite anything):

  • Check for anything recoverable: git stash list and git fsck --lost-found.
  • Open the Timeline view on affected files (right-click → Open Timeline) - it keeps snapshots outside git, so it’s your best shot at the never-committed policy files.
  • For files removed by git clean, use Windows Previous Versions / File History (git clean deletes permanently).
  • For files the agent edited that session, try Restore Checkpoint. (Checkpoints)

Straight answer: work wiped by git reset --hard or git clean usually can’t come back through git, so Timeline and OS restore points are the real chances.

Why it happened (on our side, not your setup): the trigger was Auto-Run - with it on, the agent can execute terminal commands, including destructive git like reset --hard/clean, without stopping to ask. Combined with parallel subagents sharing one working tree (no write-scope coordination), overlapping edits collided and the destructive “recovery” ran unattended. Auto-Run is a genuinely powerful tool, and that power is exactly why guardrails matter - rules alone don’t hard-stop it. This is something we’ve seen before, and I’ve logged your report with the team.

To prevent a repeat:

  1. Switch Auto-Run to approval mode. In Cursor Settings → Agents, under Auto-Run, set it to require approval (or turn Auto-Run off) so the agent asks before running terminal commands, and keep your allowlist narrow so git reset/clean/checkout/restore/stash never auto-approve. (Terminal)
  2. Commit/stash/branch before large runs - checkpoints don’t cover terminal side effects, so a manual git checkpoint is the reliable backstop.
  3. Add a beforeShellExecution hook to hard-deny those destructive git verbs. It runs ahead of Auto-Run, so it’s the strongest guard even if a model ignores its instructions (the docs have a ready-made git-block example). (Hooks)
  4. For parallel work, give each task its own worktree instead of overlapping editors in one tree. (Worktrees)