After updating Cursor, it automatically converted line endings (LF→CRLF)
in a large legacy file (47,000+ lines), mixing legitimate code changes
with line ending changes. This happened even with AI in “Ask Mode” (read-only).
Steps to Reproduce
When there is a popup for new version update, click the update button.
Expected Behavior
Cursor should preserve existing line endings by default
Updates should not modify editor settings that affect file content
Users should be warned if line ending auto-conversion is enabled
Hey, thanks for the report. Looks like a known issue with files changing on Cursor update/launch on Windows - usually tied to line endings settings and unaccepted changes from Agent/Composer.
Need a bit more info to pinpoint the exact cause:
Git config:
What does git config --global core.autocrlf return?
Cursor settings Ctrl+,:
files.eol - what’s the value?
files.insertFinalNewline - enabled?
files.trimTrailingWhitespace - enabled?
Project:
Any .editorconfig or .gitattributes in the project?
Was there a pending review from Agent/Composer in this file that you didn’t accept before updating?
Temporary workaround (based on similar cases):
If there are unaccepted changes in the Review panel - try opening each file and hitting “Accept all changes”, then revert git changes and restart Cursor. This fixed it for a few users.
Let me know the results - it’ll help figure out if we need a new ticket or if it’s a variant of the known issue.
Hi Dean,
The problem is more serious than I thought.
I just opened the app, and it updated these 3 files.
Since I started using Cursor, these are the only files I have ever asked the app to create or update.
I can see the issue is more serious. The files change every time you open the IDE, not only during an update.
This looks a lot like a bug that was fixed in version 2.3. The IDE used to add blank lines on startup to files that Agent had edited before. You’re on 2.4.27, so this is either a regression or a slightly different case related to line endings.
Main question: do you have any pending changes for these files in the Review panel?
Open the Review panel
Check if those 3 files are listed there (DataProvider.cs, CacheRace.aspx, CacheRace.aspx.cs)
If they are, try this workaround that helped many users with a similar bug:
Open each file from the Source Control tab
Click the Keep button (or press Ctrl+Y)
Remove the extra changes (in your case, revert to the original line endings)
Restart Cursor
After that, the files should stop “sticking” on IDE startup.
Let me know what you see in the Review panel and whether the workaround helped. If not, I’ll create a ticket for the team since this looks like a regression of a bug that was already fixed.
Review panel:
There are no pending changes for these files in the Review panel.
When opening Cursor, no Review panel appears, and the following files are not listed there:
* DataProvider.cs
* CacheRace.aspx
* CacheRace.aspx.cs
No Accept/Reject UI is shown at any point. The changes do not go through the Review workflow.
Findings / repro:
* DataProvider.cs contains pure CRLF line endings (LF-only lines: 0, verified at byte level).
* On reopening Cursor, the file is rewritten to LF without any user edits.
* LastWriteTime changes on reopen, confirming the file is written on open.
* This happens even when launching Cursor with --disable-extensions (so not extension-related).
* .editorconfig is being read (indentation rules apply), including [*.cs] end_of_line = crlf.
* Workspace/folder settings do not override anything.
* .gitattributes includes *.cs text eol=crlf, but Cursor still writes LF.
* files.eol was tested with “\r\n” and “auto”; behavior is unchanged.
Conclusion:
Cursor core (not Agent/Review, not extensions) is saving files on open and normalizing line endings to LF, bypassing the Review panel and ignoring EditorConfig end_of_line = crlf.
We are also experiencing this. It’s not just inconvenient, its costing us money in time. Please considering fixing this as an urgent hotfix issue. If it helps, when viewed in VS afterwards, the message appears “These files have different encodings. Left file: Unicode (UTF-8) with signature. Right file: Unicode (UTF-8) without signature. You can resolve the difference by saving the right X
file with the encoding Unicode (UTF-8) with signature.” I don’t see UTF-8 with signature as an option in the Cursor encoding dropdown, so maybe that needs to be added? In Github online, it mentioned with or without a BOM-so maybe that one too?
Same here - I have to remember to commit all work before even thinking about opening cursor otherwise it edits 300+ files to change their line endings to LF. If i forget, then my working folder is polluted with these changes and its time consuming to recover from. I have tried all VS Code settings (in Cursor) to do with line endings, and nothing works. As the OP says, this also occurs after deleting the workspace cache from AppData so that Cursor loads with no files open at all, just a new agent on screen. It still tramples over the same files on the next load. I love Cursor, but this is making the workflow difficult.
Incidentally, this is what Cursor itself advises after spending hours trying to fix it:
If it’s Cursor (no extension)
Then there is no setting we can change in your project to make it “stop touching all my files.” The only real fix is Cursor changing their code so they don’t write files when they shouldn’t. Your options are:
Report the behavior (e.g. “Cursor rewrites 100+ files to LF on startup despite files.eol and files.eolConversion”).
Check Cursor release notes / settings for anything like “indexing”, “codebase”, “normalize”, or “line endings” and turn it off if it exists.
As a last resort, use another editor for this repo until Cursor fixes it.
So: run with --disable-extensions first; that tells you whether we can fix it (extension) or we’re blocked on Cursor (core behavior).
We’re using svn for revision control, all files are committed. Then I open my project in Cursor and line endings from several files (not all) are converted from CRLF (Windows) to LF (Linux).
Cursor agent on Windows creates new files with CRLF line endings no matter what, even though LF line ending was specified in all settings (i.e., files.eol, .editorconfig, and .gitattributes), git config --global core.autocrlf is not set, and the whole project uses LF (not CRLF).
Steps to Reproduce
Set files.eol (editor setting) to \n (LF).
Create an .editorconfig in the project root with end_of_line = lf.
Create .gitattributes with * text=auto eol=lf (and no mention of crlf).
Open new chat with any model (tested with Composer 2 and Opus 4.6) and execute this prompt:
❝Create a new test file called hello_world.js that prints “Hello World” to the console when run with Node.❞
This is causing headaches for our team. I’m guessing developers at Cursor are Mac-centric, but we would really appreciate if you could give this some attention. Fancy new features are not valuable if editor basics are broken.
This bug report is a DUPLICATE of the first one below (151096). I am re-reporting because that one no longer allows comments, and Cursor’s bug reporting guidelines say that bugs affecting more users will get more attention. I see no other way to let the Cursor team know that this is still an issue affecting Windows users.
Issues with Cursor converting LF to CRLF or creating files with CRLF despite LF settings have been reported repeatedly for the past 2 months.
This issue “seemed” to be fixed for a cpl of versions recently, but is back - i am running 3.1.10 - would be good to get some acknowledgment from the cursor team of this???
This issue is very much still present. It seems that fixes followed by regressions are a very common problem with Cursor. To clarify, this is happening on macOS, in a codebase that never had CRLF ever in it before, ever.
