char_battle.zip (20.5 KB) try
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
1 Like
Hey all 
I have merged the related topics on encoding into a single thread, so we can keep everything in one place and avoid missing anyone when we share updates.
1 Like
Hey Tomasz, thanks to your file, this should be fixed in the next version of Cursor. If you have explicitly configured a file with a particular encoding (even if that encoding is counter to what the agent would’ve auto-inferred), this encoding should be maintained, so that agent edits should generally match human-written ones.
An important question though, how are you telling Cursor that your file is Windows-1250? Are you doing “Reopen with encoding…” and the status bar says Windows-1250? Or are you using the files.encoding property?
1 Like
I’m experiencing an issue with HTML and PHP files encoded in ISO-8859-1.
Whenever I use agentic features or ‘Ctrl+K’ to refactor code, the special characters across the entire file get corrupted.
I am using the files.encoding setting in the workspace configuration.
In the root of my workspace I have:
.vscode/settings.json
with the following entry:
{
"files.encoding": "windows1250",
"files.autoGuessEncoding": false
}
So the encoding is defined at the workspace level, which means it applies to all files in the workspace and its subfolders.
I am not relying on “Reopen with Encoding…” manually for each file. The expectation is that Cursor opens and saves the files using Windows-1250 automatically because of the workspace files.encoding setting.
I’m using version 2.2.44 because of the CP-850 corruption, which is the same issue as WIN1252 that has been discussed in several threads and hasn’t been fixed in the current version. Now I can’t use it anymore because everything I request displays the message “Please update to the latest Cursor version to continue using the Agent.” What should I do? Should I cancel my subscription since I’m paying and can’t use it due to the file corruption problem in the current versions, and they won’t let me use an older version that doesn’t have this problem? @deanrie
I suggest you pay attention to resolving this as soon as possible, because faced with the problem I signed up for Copilot for $10, which, integrated with Claude, I realized I no longer need to use Cursor (which costs $60). I project in Claude and use Copilot to apply the planning, so in short, I ended up saving $50 a month with this problem. However, I paid for Cursor a year in advance, and now what do I do with the credits I won’t be using anymore?
Hello Cursor Team,
is this fixed in 2.6.19?
I’ve just tested it and the iso8859-1 issue remains. I’m giving up on this; it’s been two months without any word on a fix. Cursor has become inviable for my workflow, and I’m being forced to seek alternatives.
+1 for the problem
Hey all,
The fix that @ani-anysphere worked on should land in the next client release towards the end of the month. You can already try it out by switching to Nightly (Cursor Settings > Beta), but keep in mind these are pre-release builds.
1 Like
it works 
Can you confirm it works with the latest version?
I’m still using 2.3.41 but now get warnings: This is a very old version of Cursor. Please update to the latest version at Cursor · Download
Bug persists.
Version: 2.5.26 (system setup)
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z (3 wks ago)
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.20348
Version and steps for pls.
I am still having the issue with both UTF-8 BOM and CRLF being converted to LF on the Early Access version.
Version: 2.6.20 (user setup)
VSCode Version: 1.105.1
Commit: b29eb4ee5f9f6d1cb2afbc09070198d3ea6ad760
Date: 2026-03-17T01:50:02.404Z
Build Type: Stable
Release Track: Early Access
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
working in 2.7.0-pre.78.patch.0
1 Like
Nightly version is still removing UTF-8 BOM.
Version: 2.7.0-pre.113.patch.0 (user setup)
VSCode Version: 1.105.1
Commit: 6f6ca294486449fb5e8fbae6c138d459ae95dd10
Date: 2026-03-22T08:13:33.045Z
Build Type: Stable
Release Track: Nightly
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.26200
This issue is still occurring for me on the latest nightly (2.7.0-pre.172.patch.0), and it’s affecting a large portion of my workflow—almost every agent interaction ends up corrupting source files, which then have to be analyzed and corrected, spending additional time and tokens. Since file editing is such a core operation for LLM-driven workflows, this has been pretty disruptive on a daily basis.
Is there any additional diagnostic info I can provide to help narrow this down (logs, minimal repro, specific file patterns, etc.)? I’m happy to help test fixes or provide samples if that would accelerate resolution. (It has been nearly two months since this was first reported.)
Version: 2.7.0-pre.172.patch.0 (user setup)
VSCode Version: 1.105.1
Commit: de9b12bf051590906c465a8a9a221787ec3b88c0
Date: 2026-03-31T05:49:04.779Z
Layout: editor
Build Type: Stable
Release Track: Nightly
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.26200