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

[Leonel_Silva]

bugged all files convert auto save utf8

[Leonel_Silva]

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

[Colin]

Hi @Joyfullservice!

The reproducer that @Tomasz_Siedlaczek provided earlier proved quite useful.

@Tomasz_Siedlaczek

delphi7.7z (329 bajtów)

Hello Ani,
I am sending two files: Unit1 - kopia.pas, the original file from the Delphi 7 IDE, and Unit1.pas, which was edited and saved by Cursor, despite my request not to modify any comments, messages, etc.

Regards,
Tomasz

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

[Tomasz_Siedlaczek]

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

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

Regards,
Tomasz

[Joyfullservice (Adam Waller)]

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

[Colin]

Hey @Joyfullservice!

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

@Tomasz_Siedlaczek

delphi7.7z (329 bajtów)

Hello Ani,
I am sending two files: Unit1 - kopia.pas, the original file from the Delphi 7 IDE, and Unit1.pas, which was edited and saved by Cursor, despite my request not to modify any comments, messages, etc.

Regards,
Tomasz

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!

[Joyfullservice (Adam Waller)]

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

[Joyfullservice (Adam Waller)]

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.

[Colin]

@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?

[Joyfullservice (Adam Waller)]

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

[mohitjain (Mohit)]

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.

[Joyfullservice (Adam Waller)]

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!

[mohitjain (Mohit)]

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!

[DamGio (Damián Giorgi)]

Hola Thiago, _pudiste resolver este tema? Comencé a utilizar Cursor con Delphi y al editar automáticamente los archivos pas si los reescribe rompe el encoding por mas que ponga reglas como el mismo Cursor me ha sugerido hacer. Gracias !

[Bit (Luis)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Agent patcher appears to cache a file’s original encoding by path. If a Windows-1252 file is converted externally to UTF-8 during the same Agent session, a later patch silently writes it as Windows-1252 again. This can corrupt accented characters and produce invalid UTF-8. The patcher also ignores charset = utf-8 from .editorconfig.

Steps to Reproduce

1. Create EncodingTest.cs as Windows-1252 without BOM with this content: internal class EncodingTest { private const string AccentedText = “Lo può fare.”; }

2. In a Cursor Agent chat, send this prompt: In EncodingTest.cs, add this field below AccentedText: private const string FirstAsciiText = “First patch.”;

3. Let the Agent apply the change to the file.

4. Using an external editor or script, convert EncodingTest.cs to UTF-8 without BOM.

5. Verify that “ò” is encoded as the UTF-8 bytes 0xC3 0xB2.

6. Add charset = utf-8 under [*.cs] in .editorconfig.

7. Continue in the same Cursor Agent chat and send this prompt: In EncodingTest.cs, add this field below FirstAsciiText: private const string SecondAsciiText = “Second patch.”;

8. Let the Agent apply the change.

9. Inspect EncodingTest.cs again. The “ò” character has been written as the single Windows-1252 byte 0xF2, so the file is no longer valid UTF-8.

Expected Behavior

The patcher should detect the encoding from the file’s current bytes before every write and honor .editorconfig.

After a file is converted to UTF-8, later patches should preserve UTF-8 instead of reusing previously cached encoding information.

Operating System

Windows 10/11

Version Information

Version: 3.16.17 (user setup)
VS Code Extension API: 1.128.0
Commit: 6b2afae0257df2bb5e1835f15165dc2f0de056b0
Date: 2026-08-14T01:41:12.803Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.22631

Does this stop you from using Cursor

Yes - Cursor is unusable

[Michael_Hutter]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Environment: Cursor Agent, Windows, Delphi project (Codepage 1252, no BOM on .pas)

Steps to Reproduce

Steps:

1. Open a .pas file that contains CP1252 umlauts (e.g. byte 0xFC for ü in comments).
2. Ask the agent to apply a small ASCII-only StrReplace (one line changed).
3. Save result.

Expected Behavior

Expected: Only the edited line changes; all other bytes unchanged (CP1252 preserved).

Actual: Whole file is rewritten as UTF-8. Unchanged lines with umlauts corrupt:

• 0xFC (ü) → 0xFF or similar
• 0xDF (ß) → 0x9D
  Delphi IDE then shows replacement characters.

Request: When patching files, preserve original encoding (or honor files.encoding / workspace charset).
For partial edits, write bytes for unchanged regions verbatim; encode only new/changed spans in the file’s encoding (CP1252 for our .pas).

We work around with PowerShell CP1252 patch scripts + pre-commit verify; we’d prefer native agent/tools support.

Operating System

Windows 10/11

Version Information

Version: 3.23.23 (user setup)
VS Code Extension API: 1.128.0
Commit: 2dac2428994fe34f12658d9ecad1541b98db2c00
Date: 2026-10-05T01:43:43.807Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Reproducible with Agent edits (StrReplace/Write); not model-specific.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

cursor-forum-encoding-repro.zip (2,8 KB)

[Michael_Hutter]

Merged from #173884 — same root cause on Delphi (.pas, CP1252, no BOM).
Attached repro pack: minimal SampleUnit + Compare-Cp1252Bytes.cmd (see zip in merged post).
Byte pattern: 0xFC/0xF6/0xE4 → 0xFF, 0xDF → 0x9D on unchanged lines after ASCII-only Agent StrReplace.

We use "files.encoding": "windows1252" in .vscode/settings.json (workspace-wide).

Zip includes healthy + simulated corruption; I can add before/after from a real Agent StrReplace on request.

cursor-forum-encoding-repro.zip (4,5 KB)