Cursor creates phantom unsaved changes on every restart (requires discarding multiple files)

And a root cause of the corruption:

  • Cursor’s AI edit / Composer keeps “pending” edits in a checkpoint cache in the global state.vscdb SQLite DB.
  • For each edit it stores file content as line arrays (one string per line).
  • On restart, Cursor reapplies pending diffs for files that were never fully accepted/rejected.
  • For each such file it writes the cached content over the file on disk, concatenating individual strings using \n (LF) symbol.

It should be possible to make a script with would open state.vscdb database after Cursor shutdown (it’s locked while IDE is running), find all files which have edits which are neither accepted nor rejected, check git status for these files to filter out in-progress files with actual changes, then automatically accept changes, effectively clearing the file. However, I don’t want to be too intrusive and will stick with a manual Keep All solution for a time being.

1 Like

Thanks for the research. Hopefully this info can make it to the Cursor team, so they can fix this @deanrie

I have accepted all pending changes, and yet it still happens when I start up Cursor.

1 Like

For me it works, but unreliable. For example - I have 11 files which get corrupted on each restart. The script fixes all these files and lists them in the Problems window at Cursor startup. I click each file in the Problems window to open it, click Keep All button then repeat the same for remaining files (a few month ago it was sufficient to click Keep All once and it fixed them all, but now each file must be accepted individually). Then I restart the IDE and the script reports 6 haunted files. I repeat “open-KeepAll” procedure and restart Cursor once again - now 3 files are reported. And only after third iteration I have no corrupted files.

But, as I said, the script is not a cure, it’s just a primitive tool which fixes files after they get corrupted on IDE restart and makes it a bit easier to perform open-keepAll procedure by listing all the affected files in a single place. But the script doesn’t fix the source of corruption. It should be properly fixed by Cursor developers - they should stop restoring “unaccepted” files from the checkpoint cache on each IDE startup.

1 Like

This issue is still present on the most recent update:

Version: 2.6.19 (system setup)
VSCode Version: 1.105.1
Commit: 224838f96445be37e3db643a163a817c15b36060
Date: 2026-03-12T04:07:27.435Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100

@deanrie, is there any update on this situation?

Still an issue. This is enormously frustrating since we wind up having to fix files that don’t even include real changes. We use CRLF line endings on Windows. When Cursor starts, it indexes the files.. during this phase.. it is touching the files and changing the line endings.. Why on earth does Cursor touch the files when it is starting up? I can understand a read operation on the files, but it shouldn’t be writing to them. It will occasionally convert the line endings to LF, when I have explicit rules in place not to do this (everything is CRLF). Please address this issue, it is very troubling and ultimately impacts work velocity significantly. I am paying on demand to fix the errors introduced by the tooling.. it simply doesn’t make sense.

1 Like

[FIXED]

Hi everyone, i fixed it using agent in Cursor, he wrote this instructions for you:

I was struggling with the exact same issue in my Unity project on Windows. Every time I launched Cursor, it would touch several specific files (like Player.cs and Vehicle.cs), completely rewriting them in the Git diff even though I didn’t actually make any changes. I was forced to discard these phantom changes every single time.

I asked Cursor’s AI Agent for help, and it successfully identified the root cause and implemented a permanent fix.

The Root Cause

This is a classic line-ending conflict between CRLF (Windows) and LF (Unix/Mac). When Cursor starts up, its background processes (like language servers or formatters) index previously opened files. Because Cursor is based on VS Code and often defaults to LF, it “corrects” the line endings of files that were originally saved with CRLF. Git sees this invisible formatting change and marks the entire file as modified (red/green diff with the exact same code).

The Permanent Fix

You need to explicitly force both your editor and Git to agree on a single line-ending standard (usually LF). You can do this by adding two configuration files to the root of your project:

Step 1: Create an .editorconfig file Create a file named .editorconfig in your project root to force Cursor (and any other IDE) to always use LF.

# Tell editors how to format files
root = true

# Apply to all files
[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

# Exceptions for specific files (like Unity metadata)
[*.{mat,meta,prefab,unity,asset}]
charset = unset
end_of_line = unset
insert_final_newline = unset
trim_trailing_whitespace = unset

Step 2: Update your .gitattributes file Create or edit .gitattributes in your project root to tell Git how to handle line endings so it stops complaining about CRLF vs LF.

# Auto-detect text files
* text=auto

# Force LF for scripts and text files
*.cs text eol=lf
*.md text eol=lf
*.json text eol=lf
*.txt text eol=lf
*.xml text eol=lf

# Keep specific files as they are (usually LF)
*.meta text eol=lf
*.unity text eol=lf
*.prefab text eol=lf
*.asset text eol=lf

What to do next:

After adding these two files, check your Git client (like GitHub Desktop). You will likely see a warning like: “This diff contains a change in line endings from ‘CRLF’ to ‘LF’”. Do NOT discard these changes. Commit the .editorconfig, .gitattributes, and the affected files.

This is a one-time process. Once committed, your files will be standardized to LF, and Cursor will never create those annoying phantom diffs on startup again. Hope this helps someone!

Thank you for the instructions, but this is NOT a fix, it’s a work-around. You configure both git and IDE to to use LF line endings, which is not a standard on Windows and it may cause issues if you use other applications to read/write your project files. For example, we use clang-format to enforce code style in our source files, and it’s set up to use CRLF. Yes, I can modify .clang-format file to also use LF, but this file is a part of our git repository and I cannot force all fellow developers to switch to LF just because my IDE has a bug with line endings.

1 Like

Just wanted to update that this issue is still present after the most recent update:

Version: 3.0.13 (system setup)
VSCode Version: 1.105.1
Commit: 48a15759f53cd5fc9b5c20936ad7d79847d914b0
Date: 2026-04-07T03:05:17.114Z
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.26100

@deanrie @Colin Could we get an update on this?

Hey, thanks for the update, @Leland_Hepworth. And sorry for the long silence.

The bug is still on our radar. The previous fix covered some cases, but not all, and your reports show that. I shared the updated info from this thread with the team, including the great root cause analysis from @Dmitry_Kukushkin. The checkpoint cache in state.vscdb reapplies files with LF instead of CRLF. I can’t share an exact timeline yet, but your reports help us prioritize this.

For now, workarounds that helped other users:

  1. Stage + Unstage: stage all changes, the phantom files should disappear automatically, then unstage the real changes. @Leland_Hepworth, you already know this one.
  2. PowerShell script from @Dmitry_Kukushkin: it automatically restores line endings when launching the IDE via tasks.json.
  3. .editorconfig + .gitattributes: force LF for the project. But as @Dmitry_Kukushkin noted, this doesn’t always work if your team uses CRLF.

I’ll update the thread when there’s progress on the fix.

2 Likes

The issue is still present in the most recent update:

Version: 1.116.0 (system setup)
Commit: 560a9dba96f961efea7b1612916f89e5d5d4d679
Date: 2026-04-15T00:28:13Z
Electron: 39.8.7
ElectronBuildId: 13797146
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100