Cursor AI edits corrupt Windows-1252 encoding in C++ projects (even when editor shows 1252)

Support Bug Reports
, , , ,
85

bugged all files convert auto save utf8

86

beta working fix bug Cursor AI edits corrupt Windows-1252 encoding

88

Hi @Joyfullservice!

The reproducer that @Tomasz_Siedlaczek provided earlier proved quite useful.

If you could provide something similar, we can have another look!

89

Hi,

Since switching to the Beta 2.7.xxx nightly build, the problem has disappeared. The cursor now correctly reads Windows-1250 encoded files and gracefully saves them back using the same encoding :slight_smile:

Because of this, I am no longer able to provide a corrupted file, which is actually the perfect outcome from my perspective.

Regards,
Tomasz

90

Just as an update, this problem still exists in the latest version of Cursor. It is not every time, but occasionally files will still get mangled. Most of the time it is line endings being changed from CRLF to LF, but sometimes the UTF-8 BOM is also stripped. This happens every single day. While there has been some improvement in the newer versions, the problem is definitely not fully resolved.

Version: 3.3.0 (user setup)
VSCode Version: 1.105.1
Commit: 199f9dfab72daeb2f76c4aad066fd9aeea196d10
Date: 2026-04-30T22:46:00.300Z
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

91

Hey @Joyfullservice!

If you’re able to share a reproducer like here:

That helps out a ton. I know it’s not trivial since it doesn’t happen everytime, but if you’re able to record a specific instance, what the agent did (what tools ran) and a before/after, it gets us much closer!

92

As a further update, I have been able to do some heavy programming work for the last couple of days, and I don’t believe I encountered the issue… Hopefully this means that some of the fixes have been incorporated into the core software. I will let you know if this starts happening again.

Version: 3.3.12 (user setup)
VSCode Version: 1.105.1
Commit: 75c0dfd29aecf2cc208dbaf761d5cc459c601aa0
Date: 2026-05-06T03:47:52.249Z
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

93

I spoke too soon! The bug bit again, but this time Opus 4.6 was able to get to the bottom of it…

Cursor Auto-Update Restart Rewrites Open Files with LF Line Endings

Summary

When Cursor auto-updates and restarts, files that were open in editor tabs are rewritten to disk with LF (\n) line endings, even when .editorconfig specifies end_of_line = crlf and .gitattributes specifies eol=crlf. The file content is unchanged — only the line endings are silently converted from CRLF to LF. This causes git status to report the files as modified with no actual content differences.

This appears to be a session-restoration issue: during restart, the editor reopens previously-open tabs from its internal model (which normalizes line endings to LF internally) and writes them back to disk without consulting .editorconfig or .gitattributes.

Environment

  • OS: Windows 10 (10.0.26200)
  • Cursor versions: Observed during update from 3.2.21 to 3.3.12
  • Shell: PowerShell 7
  • Project: VBA source files requiring CRLF + UTF-8 BOM for import into Microsoft Access

Project Configuration

.editorconfig:

root = true

[*]
end_of_line = crlf

[*.{bas,cls,form,report,qdef,macro,sql,frm,json,xml,txt}]
charset = utf-8-bom
end_of_line = crlf

.gitattributes:

*.bas text eol=crlf
*.cls text eol=crlf
*.sql text eol=crlf
# (and similar for other extensions)

Steps to Reproduce

  1. Open a project that has .editorconfig with end_of_line = crlf and .gitattributes with eol=crlf
  2. Open several CRLF-encoded files in editor tabs
  3. Verify git status is clean (no modifications)
  4. Allow Cursor to auto-update (or trigger a restart that causes session restoration)
  5. After restart, run git status

Expected Behavior

Files open in editor tabs should be unchanged on disk after the restart. The session restoration should respect .editorconfig and .gitattributes line-ending settings when writing file content back to disk.

Actual Behavior

All files that were open in editor tabs are rewritten with LF-only line endings. git status reports them as modified. git diff shows no content changes — only the CRLF-to-LF conversion triggers the modification flag:

$ git diff --stat
warning: in the working copy of '...clsDbProperty.cls', LF will be replaced by CRLF the next time Git touches it
warning: in the working copy of '...clsDbQuery.cls', LF will be replaced by CRLF the next time Git touches it
(etc. for all affected files)

$ git diff --numstat
(empty — no content changes, only line-ending differences)

Evidence from Logs

Cursor update triggered the restart

Previous session log (%APPDATA%\Cursor\logs\20260506T113936\main.log):

2026-05-06 11:39:37.062 [info] updateURL .../cursor/3.2.21/...
2026-05-06 11:39:54.586 [info] update#setState checking for updates
2026-05-06 11:39:54.640 [info] update#setState downloading
2026-05-06 11:39:59.367 [info] update#setState downloaded
2026-05-06 11:39:59.368 [info] update#setState updating
2026-05-06 11:42:38.858 [info] Extension host with pid 19296 exited with code: 0
(all extension hosts exit)

New session log (%APPDATA%\Cursor\logs\20260506T114347\main.log):

2026-05-06 11:43:48.394 [info] updateURL .../cursor/3.3.12/...
2026-05-06 11:43:48.394 [info] update#setState idle

File corruption timestamp matches session restore exactly

All 7 corrupted files had the exact same modification timestamp: 5/6/2026 11:43:52 AM.

The renderer log (window1\renderer.log) confirms extension hosts starting at this exact second:

2026-05-06 11:43:52.056 [info] Started local extension host with pid 25944.
2026-05-06 11:43:52.264 [info] Placing extension(s) anysphere.cursor-retrieval on a separate extension host.
2026-05-06 11:43:52.265 [info] Placing extension(s) anysphere.cursor-always-local, ...
2026-05-06 11:43:52.314 [warning] [ms-python.python]: Cannot register 'python.venvPath'. ...
2026-05-06 11:43:52.623 [info] Started local extension host with pid 25812.
2026-05-06 11:43:52.624 [info] Started local extension host with pid 25508.
2026-05-06 11:43:52.624 [info] Started local extension host with pid 15916.

Filesync log confirms the corrupted files were in editor tabs

The Filesync log (window1\exthost\anysphere.cursor-always-local\Filesync.log) shows each corrupted file being synced as a visible editor tab after the restart:

Uploaded file ...clsDbTableDef.cls modelVersion=3
Uploaded file ...clsDbImexSpec.cls modelVersion=3
Uploaded file ...clsDbProperty.cls modelVersion=3
Uploaded file ...clsDbTableData.cls modelVersion=3
Uploaded file ...clsDbQuery.cls modelVersion=3
Uploaded file ...modBuild.bas modelVersion=3

Every file in this list was found with corrupted (LF-only) line endings.

No agent tool call wrote to these files

A thorough review of all agent transcripts confirms that no Write, StrReplace, or shell write command targeted any of these files. The corruption is entirely from the IDE’s session-restoration path — not from agent tooling.

Affected Files (This Instance)

File Content change? In editor tab?
clsDbProperty.cls No Yes
clsDbQuery.cls No Yes
clsDbTableData.cls No Yes
clsDbTableDataMacro.cls No Yes
clsDbTableDef.cls No Yes
clsDbImexSpec.cls No Yes
modBuild.bas No Yes

All files had CRLF before the restart. All had LF-only after. No content differences. Only the line endings changed.

Impact

For this project, CRLF line endings are mandatory — Microsoft Access’s LoadFromText API requires them for importing VBA source files. Silent CRLF-to-LF conversion makes the source files unusable for database builds until manually corrected. The corruption is invisible until git status is checked, and since the files show no content diff, it’s easy to accidentally commit or overlook.

94

@Joyfullservice I really want this to be it!

I tried to reproduce on Windows 11 with the following setup:

  • Git repo with core.autocrlf = false and core.eol = crlf
  • .gitattributes with * text=auto eol=crlf and explicit *.cls text eol=crlf / *.bas text eol=crlf
  • .editorconfig with end_of_line = crlf and
  • 7 VBA source files (.cls and .bas) written with UTF-8 BOM + CRLF line endings
  • Committed with clean git status

After restart, all files remained CRLF

Did you have a different update path? Specifically:

  1. Was it a background auto-update that prompted you to restart (i.e. Cursor downloaded the update on its own and you clicked a “Restart to Update” notification), versus you manually triggering it from the Help menu?
  2. Did the files have unsaved changes (dirty state) at the time of the update, or were they saved but open in tabs?
95

Here is what I currently have… A lot of tabs open (mostly plans, but maybe one of the affected files.) I have two Cursor windows open. Leaving the one window open, I close the second window. In the second window, I have 7 files that are showing the mangled LF endings. I open GitHub Desktop, revert all 7 changes so everything is clean.

The current state:

  • One Cursor window open to another project. (This probably doesn’t matter)
  • All files in the example project are clean with CRLF endings.

Reproduce the issue:

  • I open a new Cursor window to my project folder.
  • After the window loads, the same 7 files now have the mangled line endings. (I did not run anything or touch any tools. It was simply the loading of Cursor that messed up the files.)
  • Note that only these seven files were affected. Hundreds of other files are unchanged. These affected files would have been modified by now complete plans that were open in existing tabs.

Is there a log file or state representation that would be helpful for you? Or a prompt that I could feed an agent to continue to the search? You can clone the exact project at GitHub - joyfullservice/msaccess-vcs-addin: Synchronize your Access Forms, Macros, Modules, Queries, Reports, and more with a version control system. · GitHub

Thanks!

Adam

100

Adam, we’ve been able to reproduce this on our end using your repo with the exact pattern you described: Agent-edited files get their CRLF endings silently converted to LF on the next workspace open. Only files with prior Agent editing history are affected, which explains why earlier reproduction attempts with clean repos didn’t trigger it.

This is being actively investigated by our engineering team.

In the meantime, one thing worth trying as a workaround: before closing Cursor, check the Review panel (the diff icon in the sidebar) and accept or discard any pending changes from previous Agent sessions. If those cached states are cleared before close, the corruption shouldn’t trigger on the next open. Let us know if that helps reduce the frequency.

Thanks for sticking with us on this and for sharing the public repo.

101

Thanks for the update, Mohit! I appreciate the efforts on resolving this issue, and I am glad to hear that you are able to clearly reproduce it on your end. That makes troubleshooting a whole lot easier! :smiley:

106

Hey everyone, the line ending conversion issue (where CRLF files were silently rewritten to LF on workspace open) has been fixed in a recent Cursor update. Updating to the latest stable version should resolve this.

Let me know if you’re still seeing this after updating!