Cursor Agent reopening old chats automatically rewrites source files

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After using Cursor Agent mode on a large legacy .NET solution, reopening old Agent chats causes Cursor.exe to automatically rewrite many source files without explicit user action.

Symptoms observed:

  • ProcMon shows Cursor.exe performing WriteFile operations against source files
  • File timestamps updated immediately after opening old chats
  • CRLF/LF normalization behavior
  • Hebrew characters sometimes replaced with question marks
  • “Inline diffs have been suppressed for recent changes because there are too many to display”
  • Some rewrites occur even when Git shows no textual diff afterward

The issue is specifically tied to reopening/restoring old Agent chats/sessions.

Deleting state.vscdb and allowing Cursor to create a fresh one stops the issue until old chats are restored again.

This strongly suggests a problem related to Agent checkpoint/session replay or stale pending edit state.

Steps to Reproduce

  1. Use Cursor Agent mode to modify files in a large .NET solution
  2. Close Cursor
  3. Restore an older state.vscdb (or reopen Cursor with previous Agent chats restored)
  4. Reopen Cursor
  5. Cursor automatically restores the last active Agent chat
  6. Open/select one of the old Agent chats
  7. Observe Cursor.exe immediately issuing WriteFile operations against many source files (confirmed via ProcMon)

Expected Behavior

Opening or restoring old Agent chats should never rewrite source files unless the user explicitly applies edits.

Screenshots / Screen Recordings

Screenshot 2026-05-21 101909.png
Screenshot 2026-05-21 101909.png1391×743 138 KB

Operating System

Windows 10/11

Version Information

Version: 3.5.17 (system setup)
VSCode Version: 1.105.1
Commit: d5b2fc092e16007956c9e5047f76097b9e626ca0
Date: 2026-05-20T02:43:31.559Z
Layout: glass
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

For AI issues: which model did you use?

Composer / Agent mode

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Additional findings:

  • The issue reproduces even when launching Cursor with:
    Cursor.exe --disable-extensions

  • Git often shows no textual diff afterward, suggesting Cursor may be rewriting equivalent content, changing BOM/encoding/line-ending metadata, or replaying normalization writes.

  • Removing:
    AppData\Roaming\Cursor\User\globalStorage\anysphere.cursor-commits
    and deleting:
    state.vscdb
    stopped the issue until old chats were restored again.

  • The repository contains mixed encodings, CRLF-sensitive files, and non-English (Hebrew) text.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. The ProcMon log and repro steps are spot on. This is a known bug with checkpoint and local-history restore. When you open older Agent chats, Cursor replays the saved state and overwrites files on disk, which updates mtime, normalizes CRLF and LF, and can corrupt non-ASCII characters. In your case it is Hebrew, and in other reports it is Portuguese and Japanese. We’ve logged the issue on our side, but there’s no ETA for a fix yet.

Main thread with discussion and workarounds: Cursor creates phantom unsaved changes on every restart (requires discarding multiple files). Your findings, deleting state.vscdb and anysphere.cursor-commits from globalStorage, match what’s working for other users. The downside is that once you restore old chats, it comes back. That’s a current limitation of the workaround.

The Hebrew corruption detail is super helpful. I’ll add it to the existing report since the encoding side is another part of the problem. If we have an update on the fix, we’ll reply in that thread.

8

Hey @avi-starvision, thread update: the fix for the phantom unsaved state and file overwrites on disk at startup is coming in Cursor 3.8. It’s not in the current stable 3.7.21 yet.

Once you update to 3.8, please rerun your scenario and let me know if the dirty dot on launch is gone, and if the WriteFile spikes in ProcMon still happen when you open older chats.

One note so there are no false expectations: the encoding symptoms like Hebrew characters and CRLF vs LF normalization are tracked separately, and this fix might not fully cover them. If you still see them after 3.8, please call that out separately in the thread and we’ll take a look at that part.