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

Support Bug Reports
, , ,
31

Sorry, in my first try I thought that the problem was solved

No, it is not solved

I still can’t use a cursor because of this problem

Please solve it

32

Any news about this issue?

I’m about to cancel my subscription.

I’m pàying for nothing …

33

When will this be fixed? Because reopening the file with a different encoding doesn’t solve the problem.

34

One month after this BIG ISSUE, the problem is not solved.

I do not understand how it can be as it …

I am looking for a replacement tool to cursor IDE …

I do not want to do it … but if the problem persists, I will replace cursor IDE with windsurf, google antigravity or github copilot.

36

In 2.5 it is still not fixed. The BOM is removed with every agent edit. Some models add it again but costs unnecessary tokens and time. Any new info on that?

37

I am seeing the same thing on my system. It is not yet fixed in version 2.5.

38

Same here in latest version 2.5.25. MSVC compiler needs UTF-8 BOM to work. Had to revert to 2.3 :crying_cat:

41

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When the agent edits a file encoded as UTF-8 with BOM, it silently strips the Byte Order Mark when rewriting the file. This changes the encoding to plain UTF-8 (without BOM), which corrupts projects that depend on BOM-encoded source files.

I’m the maintainer of msaccess-vcs-addin, a popular open-source add-in that builds Microsoft Access databases from source files. The add-in expects UTF-8 BOM-encoded files — if the BOM is missing, the build misinterprets the encoding and the build fails. The repository has hundreds of source files, so even a single stripped BOM can break the entire build.

I’ve attempted to work around this with Cursor rules that instruct the agent to verify the BOM after every edit, plus a PowerShell script to re-insert missing BOMs. Even with these measures, the rules are not consistently followed and builds still get corrupted regularly.

Steps to Reproduce

  1. Open a repository in Cursor containing files encoded as UTF-8 with BOM.
  2. Use the agent to edit one of these files.
  3. After the edit, inspect the file encoding (e.g., check the first three bytes for the BOM signature EF BB BF using a hex editor, or run Format-Hex -Path .\file.txt -Count 3 in PowerShell).
  4. Observe that the BOM has been stripped — the file is now plain UTF-8.

Expected Behavior

Cursor should detect the file’s original encoding (including the presence of a BOM) before making edits, and preserve that encoding when writing the file back to disk. Edits should change only the content the agent was asked to modify, not the file encoding.

Operating System

Windows 10/11

Version Information

Version: 2.4.31 (user setup)
VSCode Version: 1.105.1
Commit: 3578107fdf149b00059ddad37048220e41681000
Date: 2026-02-08T07:42:24.999Z
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

For AI issues: which model did you use?

Opus 4.5, Compose-1, (and others) It does not seem to matter which model you are using.

Additional Information

This likely affects any encoding-sensitive workflow on Windows, not just BOM. The suggested fix is straightforward: before writing a file, read and record its original encoding; after applying edits, write it back with the same encoding. This is standard behavior for any editor and would also address potential issues with other encodings (UTF-16, Latin-1, etc.).

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

43

Hey, thanks for the report. This is a known issue, and the same problem was already reported here: Bug: StrReplace tool strips UTF-8 BOM from files.

A fix that keeps the file encoding is expected in a future release.

For now, the best option is to use the existing PowerShell workaround. Cursor rules won’t reliably help here because the BOM is removed when the file is written, not by the model output.

I’ll update this thread when the fix is released.

45

Thanks, Dean! I appreciate the update and the pointer to the existing issues. I did not find that when search for “BOM”, “encoding”, “UTF-8”, etc… or I wouldn’t have created the duplicate issue.

This is turning out to be a real blocker in my workflow, since I basically can’t use Cursor at all to edit files. In the mean time I will have to switch over to using the Claude Code extension within Cursor to implement any plans I generate in Cursor. This is sad because I MUCH prefer the way Cursor provides real-time “thinking” feedback during agent runs instead of Claude’s ridiculous random output of meaningless adjectives.

Let me know if there is anything I can do to help this get resolved! I can only imagine that this is painfully affecting a lot of other users as well.

46

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

(Pro User here)
Cursor is consistently stripping UTF-8 BOM and messing up EOL (LF/CRLF) settings, regardless of .editorconfig or VS Code settings.

Why this is a deal-breaker:

Environment Requirements: I must use UTF-8 BOM for my specific environment. Cursor ignores this and forces a silent change to plain UTF-8.

Git Chaos: By stripping the BOM and changing line endings, Cursor creates “ghost diffs” where the entire file appears modified in Git. This makes code reviews a nightmare and ruins our commit history.

4 Months of Neglect: This bug has been reported for nearly 4 months. As a [Pro/Paying] user, it’s unacceptable that a “next-gen” IDE fails at basic file saving integrity.

Bottom line:
I’m paying for an AI tool to save time, not to spend my day manually reverting encoding and EOL changes that Cursor keeps breaking.

Fix the file-saving logic to respect existing encodings and EOL. Now.
Platform: [ Windows 11 ]

Cursor Version: [2.5.26]

Steps to Reproduce

Generate qt cpp code in Cursor’s agent mode, which must appear

Expected Behavior

keep original encoding and eol

Operating System

Windows 10/11

Version Information

Version:2.5.26(user setup)

For AI issues: which model did you use?

all

Does this stop you from using Cursor

No - Cursor works, but with this issue

48

Hey, thanks for the report. This is a known set of issues on Windows. It affects both BOM stripping and EOL (CRLF to LF) conversion. A few other users have reported the same thing recently:

There are two separate problems here:

  1. BOM stripping: When the Agent rewrites a file via StrReplace, it drops the UTF-8 BOM. This happens at the write level, so .editorconfig and Cursor rules can’t prevent it. The team is aware of this. There’s no timeline for a fix yet, but reports like yours help with prioritization.

  2. EOL conversion: Cursor’s core can normalize line endings to LF on file open or restart, ignoring files.eol, .editorconfig, and .gitattributes settings. This has also been flagged with the team.

Partial workaround for the EOL issue: if you see pending changes in the Review panel after Agent edits, open the file and click Keep All to accept them. This stops the corruption loop for those specific files, until the Agent edits them again.

For BOM, the workaround is a post-save script (for example, PowerShell) that re-inserts the BOM after Agent edits. It’s not great, but it’s the only reliable option right now.

I’ve linked this thread to the existing tracking and I’ll update here when there’s progress.

50

This problem has existed for a long time, sometimes good and sometimes bad, which affects the user experience more than the lack of functions, can it be fixed sooner?

51

This is a known set of issues on Windows

This is not an answer. This issue has been known for months, yet we’ve seen no attempt to fix it. As end users, we don’t care whether developers are aware of the bug, we care about the application working as expected and our files not becoming corrupted.

53

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

AI edits corrupt ANSI/Windows-1250 encoding in Delphi7 .pas files

Steps to Reproduce

When Cursor AI edits .pas (Delphi7) files that use ANSI/Windows-1250 encoding, it saves them as UTF-8. Polish and other non-ASCII characters get corrupted.

Expected Behavior

Detect original file encoding on open and save in the same encoding.
Actual: Files are converted to UTF-8 on save, corrupting characters.

Operating System

Windows 10/11

Version Information

Version: 2.5.26 (user setup)
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045

For AI issues: which model did you use?

Composer 1.5

Additional Information

AI edits corrupt ANSI/Windows-1250 encoding in Delphi 7.pas files :((((((

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

55

Hey, thanks for the report.

This is a known issue. AI edits convert non-UTF-8 files to UTF-8 when saving. A few threads on the same topic:

There was a fix in 2.5, but based on user reports it did not fully solve the issue. I’ll pass to the team that the bug is still reproducible on 2.5.26 with Windows-1250 encoding.

Unfortunately, there is no reliable workaround yet. files.encoding, .editorconfig, and .cursorrules do not help because the conversion happens in the apply pipeline, not in the editor.

I’ll share an update when I have news.

56

Thanks, I am looking forward for better knews

57

Hey Tomasz, can you share a sample file? Feel free to censor the content as long as it gets corrupted under the current build. I’ll add it to our test suite for this and see if we can get this fixed