AI-edited files get corrupted (CRLF→LF conversion) on IDE restart, causing data loss risk

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When Cursor’s AI modifies files on Windows, the IDE caches the AI’s version. Even after converting line endings to CRLF and saving to disk, on IDE restart Cursor restores its cached version (with LF), silently and without user consent overwriting the correct file.

  • This does NOT happen for every AI-edited file - additional trigger conditions are unknown
  • Only AI-modified files are affected, not other files
  • Corruption does not depend on whether file was open in Cursor during restart
  • The cached version in state.vscdb has LF endings
  • The file on disk had CRLF before restart
  • After restart, Cursor overwrites disk with its cached LF version
  • Once a file is affected, it gets corrupted on EVERY restart cycle (fix with unix2dos → restart → corrupted again → repeat)
  • The corruption loop stops only after opening the file in Cursor and clicking the “Keep All” button to confirm AI changes

Probable cause: Cursor caches the AI-edited file contents BEFORE the unix2dos conversion happens. On restart, it restores from cache, ignoring what’s actually on disk.

Steps to Reproduce

  1. Let AI modify a file using Agent mode (search_replace tool)
  2. AI automatically runs unix2dos to convert to CRLF (configured via AI memory/rules to always do this after file modifications)
  3. File is saved to disk with correct CRLF endings
  4. Stage the file with git add
  5. Confirm git status shows no uncommitted changes
  6. Close and restart Cursor
  7. File is now corrupted - Cursor restored its cached LF version, overwriting the CRLF file on disk

Expected Behavior

Cursor should either:

  1. Not cache AI edits, OR
  2. Check if disk contents changed before restoring from cache, OR
  3. Cache the file AFTER all AI operations complete, not immediately after search_replace

Operating System

Windows 10/11

Version Information

Version: 2.4.22 (user setup)
VSCode Version: 1.105.1
Commit: 618c607a249dd7fd2ffc662c6531143833bebd40
Date: 2026-01-26T22:51:47.692Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.26100

Additional Information

  • Git config: core.autocrlf=true
  • Project uses .gitattributes with * text=auto

Settings That Did NOT Fix It

  • .editorconfig with end_of_line = crlf
  • .vscode/settings.json with “files.eol”: “\r\n”
  • .vscode/settings.json with “cursor.chat.saveUnconfirmedCodeChanges”: false

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like
Unexpected File Modification on Startup
3

Hey, thanks for the report. This is a known class of issues on Windows. Cursor caches the file state after Agent edits, but before other processes (unix2dos in your case) change the file on disk. On restart, it restores from the cache and ignores what’s actually on disk.

Very similar issue: Topic 141010. It has 60+ posts, with lots of users seeing the same pattern (whitespace or newline changes on startup). Key point: it affects files that have unconfirmed Agent edits.

Confirmed workaround (from that thread and your description):

  • Open each file in the editor
  • Click “Keep All” to accept the changes
  • After that, the corruption loop for that file stops

One question: After you went through all files and clicked “Keep All”, did the issue fully go away, or does it come back after new Agent edits? This helps us tell if it’s a one-time cleanup or a deeper issue.

Let me know if “Keep All” fixes it for good, or if you need to do it again after new edits.

4

Thank for replying Dean,

I’ve just performed an experiment:

  • Pre-requisites: a few “dirty” files in git checkout folder caused by the issue happened during the last restart. The files have no actual changes, just wrong line endings.
  • Reverted one of the files to clean all changes (git doesn’t show it as modified any longer)
  • Accepted all AI changes (keep All) in Cursor
  • Told AI to modify the same file by adding dummy comment
  • Staged the file in git
  • Restarted IDE => Git marked the file as modified with no changes except for crlf

I.e. the “keep all” button stops corruption loop, but doesn’t mark the file with “will never corrupt again”. If it’s edited by AI again it may enter the loop again. But if AI doesn’t touch it - it’s safe.

P.S. An additional clarification (sorry, it was not clear in my original message). The “keep all” button stops the loop completely, for all the affected files at once. I don’t have to open each and every file and click the button multiple times. I don’t even have to open all broken files, it’s enough to open one of them, to the button appear.

5

An update: After my experiment described in the previous message, things got worse. Now that “test” file as well as a few others always get corrupted after restart, and there’s no “Keep All” button shown any longer, so I cannot use a work-around.

Updated: Fixed the issue by asking AI to edit any file, got the “keep all” button by opening that file and stopped the update loop.