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

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hello Cursor team,

I’m reporting a reproducible encoding corruption issue affecting C++ projects that use Windows-1252 (ANSI).

Environment

Cursor 2.4.27 (Stable)

VSCode 1.105.1

OS: Windows 10 x64

Project type: C++ (legacy codebase)

File encoding: Windows-1252

Line endings: CRLF

Project constraints

This is a legacy C++ project that must remain in Windows-1252 for compatibility reasons (toolchain, resource files, existing assets). Migrating to UTF-8 is not currently an option.

Configuration already applied

files.encoding = windows1252

files.autoGuessEncoding = false

EditorConfig with charset = windows-1252

.gitattributes with * text=auto

No format-on-save, no code actions on save

The problem

If I manually edit and save the file → no corruption

If I ask Cursor AI to do a minimal change (e.g. remove a single line) and apply it:

The entire file content gets corrupted

Accented characters (ç, ã, é, etc.) turn into ç, ã, é, etc.

Status bar still shows “Windows-1252”, even though the bytes were clearly rewritten incorrectly

This strongly suggests that the AI apply / patch mechanism rewrites the file as UTF-8 internally, ignoring the original encoding, while the UI continues to report Windows-1252.

Key observation

The corruption does not happen on open or manual save — it happens only when Cursor AI applies changes.

Expected behavior

When applying AI edits:

Preserve the original file encoding

Or at least detect non-UTF-8 encodings and avoid rewriting the full file

Impact

This makes Cursor unsafe to use on C++ legacy projects with non-UTF-8 encodings, as a single AI edit can silently corrupt the entire file.

Request

Is this a known issue?

Is there a setting or flag to force AI edits to respect the file’s original encoding?

If not, please consider this a bug report, as it breaks real-world C++ legacy codebases.

I’m happy to provide a minimal repro if needed.

Thanks.

Steps to Reproduce

Cursor 2.4.27 (Stable)

VSCode 1.105.1

OS: Windows 10 x64

Project type: C++ (legacy codebase)

File encoding: Windows-1252

Line endings: CRLF

Expected Behavior

…

Operating System

Windows 10/11

Version Information

Cursor 2.4.27 (Stable)

VSCode 1.105.1

OS: Windows 10 x64

Project type: C++ (legacy codebase)

File encoding: Windows-1252

Line endings: CRLF

Does this stop you from using Cursor

Yes - Cursor is unusable

3

Hey, thanks for the detailed report.

Related threads:

What definitely DOESN’T work (other users tried it):

  • Manual “Reopen/Save with Encoding”
    • The corruption already happened on the server before the diff came back to the editor
  • User rules in .cursorrules
    • Doesn’t help because the corruption happens in the apply pipeline, not in the prompt
  • files.encoding settings and .editorconfig
    • They get ignored

What works right now:
Downgrade to version 2.3.41 from Download · Cursor and turn off auto-update. A few users in the threads above confirmed the issue doesn’t reproduce on 2.3.x.

4

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The StrReplace tool in Cursor removes the UTF-8 BOM (Byte Order Mark) when editing files, even if the file originally had UTF-8-BOM encoding. This causes issues for projects that require UTF-8-BOM encoding (e.g., proprietary systems, legacy codebases).

Actual Behavior

StrReplace strips the BOM and saves as UTF-8 without BOM.

Impact

  • High severity for projects requiring UTF-8-BOM
  • In our case: 102 files across 6-month project required manual BOM restoration after every batch edit
  • Manual PowerShell workaround needed after each edit

Real-World Context

Enterprise ERP project with proprietary language:

  • 102 source files edited to remove sensitive data
  • ALL require UTF-8-BOM for the proprietary compiler
  • Without BOM: compilation errors, incorrect display of special characters (Polish: ąćęłńóśźż)

Proposed Solution

Preserve original encoding (including BOM) when saving files - matching behavior of VS Code, Notepad++, etc.

Workaround

Run PowerShell after each StrReplace batch:

$content = Get-Content $file -Raw -Encoding UTF8
[IO.File]::WriteAllText($file, $content, [Text.UTF8Encoding]::new($true))

Environment: Windows 10.0.26200, Cursor latest version

Steps to Reproduce

  1. Create a test file with UTF-8-BOM encoding using PowerShell:

    $content = “test content”
    [System.IO.File]::WriteAllText(“test.fml”, $content, [System.Text.UTF8Encoding]::new($true))

  2. Verify the file has BOM (first 3 bytes should be EF BB BF)

  3. Use Cursor’s StrReplace tool to edit the file (any string replacement)

  4. Check encoding again - BOM is gone!

Expected Behavior

StrReplace should preserve the original file encoding, including BOM if present.

Operating System

Windows 10/11

Version Information

Version: 2.4.27 (user setup)
VSCode Version: 1.105.1
Commit: 4f2b772756b8f609e1354b3063de282ccbe7a690
Date: 2026-01-31T21:24:58.143Z
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.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey @IgorS!

Thanks for reporting. This will be fixed in 2.5.

8

This version is also having problems. What’s going on? Why aren’t you fixing this? There are already a lot of complaints and nobody is resolving it; I’m going to cancel my plan

.

13

Even though it may not seem like there is concern about resolving it, to help, I noticed that the problem occurs much worse when undoing actions — when undoing a line, practically the entire file becomes compromised.

15

This problem should be fixed in 2.5, the release of which is imminent!

16

I don’t know exactly what the 2.5 version will fix, but (in 2.4.27) I’m using Windows-1252 encoding, and I noticed that switching chats can change the encoding even before the model begin its chain of thought

17

Use this one, it works until they resolve the issue.

image
image361×288 4.87 KB

18

Anyway, in version 2.5, and the problem still persists. Reverting to a previous version to fix it is not an option, the amount of lost improvements is terrible.

19

I’m having the same problemn in a Delphi 10 legacy application. Spending a lot of time and tokens fixing it, what a disgusting thing… Please fix it!!!

20

Obs: I’m using cursor latest version (2.5), an the problem persists

21

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

23

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.

24

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.

25

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.

26

The “Keep All” work-around doesn’t always works. Sometimes it does, sometimes it fixes a few files but keeps a few other in a corruption loop, sometimes it doesn’t help at all. I’m considering stopping using Cursor - I’m dead tired of resetting state of numerous files each time I restart the IDE. It wouldn’t be a too big deal if it was a single repository, but when numerous git submodules are used and I have to fix endline issues in most of them - this is a really big issue.

27

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The search_replace tool corrupts special characters (á, é, í, ó, ú, ñ) in Delphi .pas files encoded as ANSI/Windows-1252, even when modifying small sections of code.

Steps to Reproduce

  1. Open a Delphi .pas file with ANSI/Windows-1252 encoding containing Spanish characters
  2. Use search_replace to modify any section of the file
  3. Special characters get corrupted (e.g., ‘á’ becomes ‘á’, then ‘úscula’)

Expected Behavior

The tool should preserve the original file encoding and not corrupt existing special characters.

Actual Behavior:
Special characters are corrupted even in lines that were not directly targeted for modification, but were part of a larger context block.

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.3.35 (user setup)
VSCode Version: 1.105.1
Commit: cf8353edc265f5e46b798bfb276861d0bf3bf120
Date: 2026-01-13T07:39:18.564Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.19045

For AI issues: which model did you use?

Automatic

Additional Information

  • File encoding: ANSI/Windows-1252
  • File type: Delphi .pas source files

Does this stop you from using Cursor

Yes - Cursor is unusable

29

Hey, thanks for the report. This is a known issue. The agent currently always saves files as UTF-8, even if a different encoding is set in the workspace.

Temporary workaround:

  • After the agent edits a file, manually re-save it as Windows-1252 (bottom-right corner of the editor, click the encoding, then “Save with Encoding”, then Windows-1252)
  • Or try using CTRL+K for inline edits instead of the agent. It may mess up the encoding less, but it’s not guaranteed

Can you share the Request ID from the most recent broken generation? Click the three dots in the top-right of the chat, then Copy Request ID. I’ll link your report to our internal ticket to raise the priority of the fix for Delphi and ANSI files.

30

I do not know what do you refer with the Request ID from the most recent broken generation.

There are not three dots in the top-right of this chat.

The problem started very recently (7 days?).