Edited Files Queue Polluted by Prior Resolved Changes

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Previous changes will reappear, seemingly at random, in the edited files queue when the agent edits a file. The agent has not, in the turn where the previous change reappears in the queue, actually edited the file that the previous changes apply to. These changes appear to be from the immediately-prior session’s edits, but I have not tested this to confirm.

Rejecting the changes causes an old version of the file to appear in the “Changes” tab. This old version of the file must then be discarded to avoid reverting the current version.

The unchanged file does not appear in the “Changes” tab UNTIL the change is rejected, in which case it appears in the “Changes” tab. This demonstrates that the “edit” in the queue does not actually exist and was not actually performed by the agent in the turn where the file is incorrectly reinserted into the edited files queue.

I have not tested what happens if the user accepts the already resolved changes that were reinserted into the queue. Does it change the file? Does it not change the file? Who knows, we shouldn’t be here to begin with.

I suggest this is likely a cache invalidation bug where the system fails to clear all of the changes from a cached version of the edited files queue so the next time the edited files queue is loaded (whether from opening the IDE, or permitted the agent to edit a file), the invalid cache is loaded and the user is asked to revisit changes that have already been resolved.

Steps to Reproduce

The most common way to reproduce the bug is to:

  • Have the agent edit a bunch of files.
  • Resolve those changes so the edited files queue is empty.
  • Close the IDE.
  • Reopen the IDE.
  • Have the agent edit other files.

Every so often, the edited file queue then picks up changes that were resolved in prior sessions.

Expected Behavior

Reloading the IDE or permitting an agent to edit a file should not repopulate the edited files queue with previously resolved changes. Once the user resolves a change from the edited files queue, it must stay resolved.

Operating System

Windows 10/11

Version Information

Version: 3.5.17 (user setup)
VSCode Version: 1.105.1
Commit: d5b2fc092e16007956c9e5047f76097b9e626ca0
Date: 2026-05-20T02:43:31.559Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19044

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

This is a known bug. The diff review system doesn’t fully clear its persisted state when you accept changes, so old diffs can resurface after restarting the IDE. Your cache invalidation hypothesis is essentially correct.

Our team is aware and actively tracking this. A fix has been developed but hasn’t shipped to Stable yet.

In the meantime, here are a few workarounds:

  1. Quick dismiss: When phantom diffs appear, open each file and press Ctrl+Enter (or click Keep File) to accept the current file state and clear the stale diff

  2. Git shortcut: Stage all changes in git (git add .). The phantom changes will disappear since git recognizes the content is already committed. Then unstage any real changes you want to keep pending

  3. Nuclear option (if persistent): Clear the checkpoint cache folders. In your case (Windows), delete the contents of:

    • %APPDATA%\Cursor\User\History

    • %APPDATA%\Cursor\User\globalStorage\anysphere.cursor-commits\checkpoints

    • %APPDATA%\Cursor\User\globalStorage\anysphere.cursor-retrieval\checkpoints

    Important: back up these folders first — deleting them will clear your local undo history across all workspaces.

Let me know if any of these help, or if the issue persists after trying them.

8

Thank you Mohit I appreciate your response and suggestions.