VB6 code (.frm, .bas, .cls, .ctl) are being returned from ia agent as UTF-8 by Cursor, even with an explicit Windows-1252 configuration in the workspace. This corrupts Portuguese accented characters.
Expected Behavior:
VB6 files should be saved in Windows-1252 (VB6 default)
The “files.encoding”: “windows1252” setting in .vscode/settings.json should be respected
Current Behavior:
Files are saved as UTF-8
Accented characters are corrupted (e.g., “ação” → “ação”, “peça” → “peça”)
VB6 cannot read these files correctly
Steps to Reproduce
Ask to make any change on a Win 1252 encoded file and the entire file and all accented characters will be replaced by ???
Expected Behavior
to not change the encode from the returned code
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Hey, thanks for the report. This is a known issue. The AI agent currently always saves files as UTF-8, no matter what encoding is set in the workspace. The team is working on a fix.
For now, here’s a workaround:
After the Agent edits the file, manually re-save it as Windows-1252 (bottom-right corner of the editor → click the encoding → “Save with Encoding” → Windows-1252)
Or use CTRL+K for inline edits (they may break encoding less, but it’s not guaranteed)
So I can link this report to our internal ticket, can you share the Request ID from the latest broken generation? You can find it in the chat menu (three dots in the top-right → Copy Request ID).
Good morning @deanrie . Thanks for the quick response, and sorry for my delayed reply. I was waiting to gather more information before responding. Please note in the image how the direct response turned out. Notice that the encoding remains correct.
Could you please confirm whether you installed version 2.0 and not 2.1 or higher? When I try to run version 2.0, Cursor won’t let me continue without updating.
Maybe they saw your last post and remembered to block it on the server side .
As soon as the problems started, I tried to roll back to version 2.3, which seemed to be the most recent version that was still working. However, the update was still being forced, even after setting the preferences to not update automatically and blocking it via firewall.
When you mentioned that you were using version 2.0, I had hoped that, being an older version, it might still work—but unfortunately, not this time. : (
@deanrie , would it be possible to open an exception and allow the use of older versions until the issue is resolved? As it is now, it’s impossible to use the editor. Several question marks were added throughout the entire project’s code, causing bugs that I now have to hunt down manually. If we could use any older version where this issue didn’t exist, that would already be a temporary solution.
Thanks for the info.
About unlocking old versions, that’s not my call, but I’ll pass the request to the team. I get the logic. If the current version breaks things and downgrade isn’t possible, it leaves users stuck.
Bug status: The team is aware. A few threads about this are active right now. Windows-1252, EUC-KR, and other encodings. The bug affects multiple languages and projects.
What you can try right now (if you haven’t already):
Use CTRL+K (inline edit) instead of Agent. For some users it works better with non-standard encodings.
Just to acknowledge the suggested workaround — “After the Agent edits the file, manually re-save it as Windows-1252 (bottom-right corner of the editor → click the encoding → ‘Save with Encoding’ → Windows-1252)”:
Unfortunately, this doesn’t work either. The code edited by the agent “on the server side” returns the code to de editor with replaced accented characters by question marks . This ends up corrupting the code, even when it is manually saved using the desired encoding.