Inline edits break encoding in legacy project (umlauts corrupted, used to work)

Support Bug Reports
1

Describe the Bug

I’m working on a legacy Windows project (PRG files, old single‑byte codepage, not UTF‑8) using Cursor. Since one of the recent updates, AI inline edits started to corrupt the encoding in the edited regions: umlauts in comments and string literals turn into ? or weird characters (e.g. WerksauftrΣgen instead of Werksaufträgen).
Before that update, the exact same inline edits on the same files were applied without any encoding issues. Now it looks like Cursor writes patched parts in UTF‑8 while the file on disk is still in an ANSI/Windows‑1252 style encoding.

Steps to Reproduce

  1. Open a legacy .prg file in an external editor (e.g. Notepad++) that is encoded as OEM 850 / ANSI, not UTF‑8, and contains German umlauts in comments/strings (e.g. für äöüÄÖÜß).
  2. In Cursor/VS Code, set the file encoding for this workspace to CP437 (Status bar → Encoding → Reopen/Save with CP437), open the same .prg file, and use an AI inline edit to modify a line containing umlauts (for example a msgbox(“…für äöüÄÖÜß”)); accept the patch and save.
  3. Reload the file in Notepad++ (still using OEM 850 / ANSI) and compare: unchanged lines still show correct umlauts, but lines touched by the Cursor inline edit now show garbled characters instead of umlauts, indicating that the patch corrupted the encoding despite the CP437 setting.

Expected Behavior

With the same project and the same VS Code/Cursor encoding settings (CP437), inline AI edits on these .prg files used to work without any encoding issues: umlauts and other non‑ASCII characters in comments and string literals remained byte‑identical, and the legacy OEM‑850/ANSI files stayed intact. The current behavior should match that previous state again – applying an inline edit must not change the underlying encoding or corrupt characters anywhere outside the actual text changes.

Screenshots / Screen Recordings

Cursor Encoding Bug 2025-12-17.png
Cursor Encoding Bug 2025-12-17.png1594×1001 61.1 KB

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.2.20 (user setup)
VSCode Version: 1.105.1
Commit: b3573281c4775bfc6bba466bf6563d3d498d1070
Date: 2025-12-12T06:29:26.017Z
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

Does this stop you from using Cursor

Yes - Cursor is unusable

1 Like
2

Downgrade version is without effect, i think they break it in API edit, i hope they will fix soon.

3

Hey, thanks for the report. The encoding issue with AI edits in non-UTF-8 files is a known bug that the team is already tracking.

I’ll pass it to the team for prioritization - legacy encoding support is critical for projects with PRG/ANSI files.

1 Like
5

I found a strange thing about this problem, if I delete the appdata Cursor folder, it fixes it, but of course the settings are gone, but it doesn’t change any strings, but then after a few prompts it breaks again and it overwrites the names again and saves the encoding of the entire file to UTF8 despite the settings I have set, by default I have .cpp files set to ANSI, it’s old code, please fix it, it really didn’t work before.

6

Thanks for the extra info about the temporary workaround by deleting the AppData folder. It’s interesting that the issue comes back after a few prompts, and that .cpp files get converted to UTF-8 even though you have ANSI set.

We’re tracking a few related bug reports about encoding being changed during AI edits on non-UTF-8 files.

I’ll keep you posted once we have a fix.

7

Sorry to bother you, but is there any news yet?

8

Hey, thanks for following up.

The encoding issue is still being tracked by the team - it’s in our backlog but I don’t have a specific timeline for the fix yet.

I’ll update this thread when we have news on the fix.