Simply opening the workspace (folder) in Cursor causes the line endings (EOL) of a specific file to be rewritten on disk. The user did not perform any save operation (auto-save is also turned off)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

英語版は以下です。

Summary

Simply opening the workspace (folder) in Cursor causes the line endings (EOL) of specific files to be rewritten on disk.
The user does not perform any save operation (auto-save is also turned off).

Expected

Opening a folder alone should not modify the contents or EOL of source files.

Actual

Only specific files (e.g., certain *.cpp files or files under specific subfolders) have their timestamps updated, and the diff shows only CRLF/LF changes (or other line-ending-related differences).

Steps to Reproduce

Steps to Reproduce

  1. Launch Cursor with an empty session, then simply open the workspace/folder.
    → The line endings of specific files are rewritten automatically.
  2. After reproduction, run svn diff to confirm that only EOL-related changes are present.

Expected Behavior

Simply opening the folder should not modify the source file contents or their line endings (EOL).

Operating System

Windows 10/11

Version Information

version:2.6.22

For AI issues: which model did you use?

Compser 2 Fast

Additional Information

  • settings.json
    {
    “files.autoSave”: “off”,
    “files.hotExit”: “off”,
    “window.restoreWindows”: “none”,
    “files.autoGuessEncoding”: true,
    “files.eol”: “\r\n”,
    “files.trimTrailingWhitespace”: false,
    “files.insertFinalNewline”: false,
    “editor.formatOnSave”: false,
    “editor.formatOnSaveMode”: “file”,
    “editor.codeActionsOnSave”: {},
    “editorconfig.enable”: false,
    “C_Cpp.formatting”: “Disabled”,
    “[cpp]”: {
    “editor.formatOnSave”: false,
    “editor.defaultFormatter”: null,
    “editor.formatOnPaste”: false,
    “editor.formatOnType”: false
    },
    “[c]”: {
    “editor.formatOnSave”: false,
    “editor.defaultFormatter”: null,
    “editor.formatOnPaste”: false,
    “editor.formatOnType”: false
    }
    }
  • The issue still reproduces even after deleting %APPDATA%\Cursor\User\workspaceStorage.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. Repro steps, settings, version, everything’s there.

This is a known bug. On startup, Cursor restores cached states of the Review panel with leftover AI edits from Agent or Composer. While restoring the buffer, EOL normalization kicks in, so the file gets rewritten to disk with different line endings, even if auto-save is off and files.eol: "\r\n". That’s why it only hits files that were previously edited via AI.

I reported this internally. It’s on the radar, but I can’t share an exact ETA for a fix yet.

What you can do right now to mitigate it:

  1. Before closing Cursor, open the Review panel using the diff icon in the sidebar and accept or discard any pending AI edits. If there’s nothing cached to restore, files shouldn’t get rewritten on startup.
  2. You can also temporarily disable files.autoGuessEncoding which is true in your settings.json. In some cases it makes things worse when reading the file.

If the issue still happens after clearing the Review panel on a clean startup with no pending changes, let me know. It’d help to dig deeper. We’ll post an update in this thread once there’s news on the fix.

8

Quick update: the fix is already rolled out internally on our side, and the issue is closed on our end. It should ship in one of the next updates.

Please update Cursor to the latest version when it becomes available, then try to reproduce the EOL rewrite in a workspace where you previously had AI edits. Please check two things:

  1. Open the Review panel once and make sure there are no unfinished pending AI edits left before you close Cursor.
  2. Reopen the workspace and run svn diff to see if any files show changes only because of EOL.

If this still reproduces on the new version, reply here with the new version number and I’ll dig in further. If it doesn’t, great, glad we got it resolved.

9

Hey @amasub,
The issue with line endings being silently rewritten when opening a workspace has been addressed in a recent Cursor update. Updating to the latest version should resolve this — let me know if you’re still running into it!

10

Line endings are fixed after the update — thank you.

However, we still see a separate bug: opening the workspace (or opening specific files) silently rewrites file contents for Shift-JIS / CP932 files without BOM (legacy C++ sources). Japanese text appears as mojibake in Cursor, and the file on disk is then saved with the wrong encoding even when we did not intentionally edit or re-encode the file.

The same files display correctly in Visual Studio with Shift-JIS. This is not a “user picked wrong encoding” case — Cursor appears to change the file on open/save.

Cursor version: [3.4.20]
OS: Windows [25H2]
Steps: Open workspace → open file → (no edit) → file on disk changes / SVN shows diff

(attachments)

dff.png
dff.png1785×496 32.2 KB

11

Hey, glad to hear the EOL issue is fixed.

What you’re describing now is a separate bug. Based on the screenshot, the encoding is detected correctly: the status bar shows Shift_JIS + Win for both files. So the problem isn’t on open. It’s happening on a write trigger. Something is making Cursor re-save the file, and at that moment the bytes get corrupted.

First, try this workaround. Some cases are fixed by turning off auto-detect and setting the encoding explicitly.

  1. In settings.json:
    "files.autoGuessEncoding": false,
"files.encoding": "shiftjis"
  2. Add a per-language override to be safe:
    "[cpp]": { "files.encoding": "shiftjis" },
"[c]":   { "files.encoding": "shiftjis" }
    If the files use extended CP932 characters like NEC special characters, IBM extensions, and so on, also try "cp932". In VS Code and Cursor they usually map the same way, but it’s worth testing.
  3. Fully close Cursor, reopen the workspace, open the problematic .cpp, and immediately run svn diff without making any edits.

If the diff still shows changes even with the encoding set explicitly, then this is a separate write bug that should be reported. I can put it into a new ticket if you send:

  • What the status bar shows on open: encoding + EOL
  • What exact trigger causes the write: just opening the file, switching files, focusing the editor, or something else
  • A hex snippet of the problematic bytes before and after from svn diff like using --diff-cmd with hex output, or a screenshot of the mojibake area plus the same area from a backup

Since this isn’t EOL anymore, it’s better to start a separate thread in Bug Reports so it’s easier to track. Let me know how it goes.