Agent Review "Undo all" reverts working tree on disk (destructive, not dismiss-only)

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

Clicking “Undo all” in Agent Review did not dismiss stale review items — it reverted the local working tree in a different repo (algorithmus-wa-console). ~101 files showed as deleted/modified in git status even though main was already committed and synced with origin/main (8b400db). Review count jumped from 104 to 173

Steps to Reproduce

  1. Complete a large Agent session in repo A (algorithmus-wa-console): 100+ files across docs/, scripts/, src/, tests/ (CONSOLE-2 through CONSOLE-31).
  2. Commit and push to origin/main. Verify: git status clean, branch up to date.
  3. Open a different workspace in Cursor (wa-agent-unilatino).
  4. Agent Review panel shows ~104 pending files (paths from algorithmus-wa-console).
  5. Assume items are stale and click “Undo all” to clear the review queue.
  6. In algorithmus-wa-console run: git status
  7. Observe ~101 files changed (mostly deletions). Review panel may show ~173 files.
  8. Recovery: cd algorithmus-wa-console && git restore .

Expected Behavior

“Undo all” / dismiss should only clear the Agent Review UI queue. It should NOT modify files on disk for work already committed at HEAD. If any filesystem revert is possible, Cursor should show a strong confirmation naming the affected repo and file count (e.g. “This will revert 101 uncommitted changes in algorithmus-wa-console”).

Operating System

Windows 10/11

Version Information

IDE:
Version: 3.9.16 (user setup)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
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

CLI:
cursor --version → 3.9.16 (042b3c1a4c53f2c3808067f519fbfc67b72cad80 x64)

For AI issues: which model did you use?

Auto / Agent (multi-file agent sessions across CONSOLE and wa-agent-unilatino workspaces). Exact model varied per turn; issue is Agent Review UI behavior, not model output quality.

Additional Information

Request ID not captured before undo; can reproduce on demand.
Impact: Silent mass deletion/revert risk. Easy to mistake “Undo all” for safe cleanup of stale review when work is already on origin/main.

Affected paths (examples): docs/console-.md, scripts/validate-eva-connector-.mjs, scripts/run-eva-connector-non-live-harness.mjs, src/app/verticals/eva/status/page.tsx, src/components/eva/, src/lib/eva/, tests/run-console*.mjs

Repos:

  • algorithmus-wa-console @ 8b400db (affected on disk)
  • wa-agent-unilatino @ c5db25f (unaffected, active workspace)

Suggested fixes:

  1. Decouple Agent Review dismiss from filesystem writes
  2. Never undo files matching committed HEAD
  3. Scope destructive actions to active workspace with repo path in confirmation
  4. Split “Dismiss review” (UI only) vs “Revert agent changes” (destructive)

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the detailed report, the steps, version, and path list really help.

This looks like a known issue in a cluster of bugs around Agent Review. There are two parts to it: review markers are an inline diff overlay on top of files, not Git, and the agent writes to disk immediately. The overlay also doesn’t always fully clear after accept or commit, so stale review items for already committed files can show up again, including when switching workspaces. Undo all is a destructive action that rewrites files on disk, not just a UI dismiss, and right now it doesn’t ask for confirmation that shows the repo name and file count. This is reported internally and being tracked, but I can’t share an ETA for a fix.

What you did to recover was correct, running git restore . in the affected repo is the right move.

Until a fix lands, a couple precautions:

  • Don’t click Undo all just to clear the queue if items look stale, it’s not a UI only dismiss.
  • Keep regular commits so git restore and git reflog are always there as a safety net.
  • If review shows paths from another repo or workspace, treat it as potentially destructive, not harmless junk.

I’ve added your fix suggestions to the report: separate dismiss from disk writes, don’t touch files that match HEAD, add a strong confirmation with repo name and number of files, and split Dismiss and Revert. Let me know if you find any new repro details.