Huge amount (80+ now, growing) of obsolete changes/files tabs popping up, every time i restart Cursor

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Starting Cursor, then opening a Project i am working on, brings back countless changes (file tabs).
Deleting in roaming data the back ups - doesnt help.
AI also cant help.
Only deleting the entire roaming directory helps. (but that is not cool for obvious other reasons).

Steps to Reproduce

for me:

  • work on my project (using perforce)
  • close idea after doing some changes
  • opening ide again

Expected Behavior

  • i get warned about any pending changes like in other programs
  • no accumulation of old and obsolete changes on startup

Operating System

Windows 10/11

Version Information

Version: 3.5.38 (user setup)
VSCode Version: 1.105.1
Commit: 009bb5a3600dd98fe1c1f25798f767f686e14750
Date: 2026-05-26T21:32:06.537Z
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.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, this is a known bug: phantom unsaved or modified files after restarting on Windows. It reproduces, but there’s no ETA for a fix yet.

In your case (Windows + Perforce), a common root cause is EOL conversion (CRLF↔LF) during startup indexing. If your sources are in CRLF, Cursor can rewrite them to LF and they show up as modified. Here’s what to try:

  1. Lock the EOL in settings.json:

    "files.eol": "\r\n"

    Also check the files are actually CRLF. You can see CRLF or LF in the editor status bar in the bottom right.

  2. Quick fix without a restart: press Ctrl+E (toggle editor layout). Often the phantom changes disappear right away.

  3. Turn off restore state in Settings:

    • files.restoreUndoStack: false
    • workbench.restoreEditors: none

  4. Clear accumulated state (close Cursor first):

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

This is less drastic than deleting the whole %APPDATA%\Cursor. Let me know what helped, especially whether locking EOL fixes it. That would help with diagnosis.

7

I cannot believe we’re still dealing with this issue, I’ve found bug reports spanning multiple major versions and lots of supposed fixes that never seem to fix it. I am so close to churning and taking my money elsewhere. How is there no ETA? Please prioritize this.

9

I 2nd this. Why is this not a priority? Bug has been around for months.

12

Hey, I get the frustration. This bug is really annoying, and the fact it’s been around for more than one release sucks. I won’t sell you optimism. The issue is reproducible, it’s been reported internally and it’s a known issue, but I don’t have an honest ETA for a fix right now.

Until it’s closed, there are a few workarounds that, for some users, noticeably reduce the pain (more details in the post above):

  1. Disable state restore in settings.json:
    "files.restoreUndoStack": false,
"workbench.restoreEditors": "none"
  2. If your files use CRLF, pin the EOL so startup doesn’t rewrite them to LF:
    "files.eol": "\r\n"
  3. Clear the accumulated state (close Cursor first):
    • %APPDATA%\Cursor\User\History
    • %APPDATA%\Cursor\User\globalStorage\anysphere.cursor-commits\checkpoints
    • %APPDATA%\Cursor\User\globalStorage\anysphere.cursor-retrieval\checkpoints

This is less drastic than deleting the entire %APPDATA%\Cursor.

One quick question so I can match your case correctly. What version control are you using, Perforce, git, TFVC, or something else? The symptom looks the same, but the triggers differ between non-git and git setups, and that affects which active report I should link you to. Once I have an update on the fix, I’ll reply in the thread.