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
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 äöüÄÖÜß).
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.
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.
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.
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.
Can anyone confirm whether the encoding problem has been fixed in the current version dated February 17, 2026? In any case, it is not listed as a bug fix in the official changelog.
It’s getting worse and worse. I was able to use an older version again by uninstalling cursor, but the problem still persists. Previously, downgrading had helped. Perhaps there are settings or files in the user profile folder %appdata% that are still causing the problem?
Another tip that will hopefully help fix the encoding bug.
I’m working with 2.3.41, but after a while the encoding problem reappears here too. When I delete the cursor folder in %appdata%, it works again for a while.
I tried to pinpoint it to a specific file in the profile, but unfortunately without success. Do you have any tips for me?
I’m not sure when it happens, but possibly when I edit ANSI and UTF8 files in two projects (windows) at the same time.
