When using the cursor agent to generate code, an error occurred with garbled characters

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When I use the agent to generate code, the content in the dialog box is normal, but the generated code file actually contains garbled characters.

Steps to Reproduce

Run the agent to generate the code.
Check the content displayed in the dialog box – it should appear normal and readable.
Save or open the generated code file.
Observe that the code file contains garbled characters instead of the expected code.

Expected Behavior

The code file should be generated in UTF-8 format to ensure that the Chinese characters are not garbled.

Screenshots / Screen Recordings

ScreenShot_2026-04-27_163104_436.png
ScreenShot_2026-04-27_163104_436.png925×568 43.2 KB

Operating System

Windows 10/11

Version Information

Version: 3.2.11 (user setup)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
Layout: editor
Build Type: Stable
Release Track: Default
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

For AI issues: which model did you use?

composer2、gpt-5.4、codex-5.3

For AI issues: add Request ID with privacy disabled

3f0dc9ad-d5e6-42af-b16e-07dc23368d43

Additional Information

I’ve noticed that this issue has been happening for almost a month, and I hope it gets resolved soon. Until it’s fixed, my colleagues and I will likely not subscribe again, as this is a simple but productivity-draining problem. We hope it will be addressed as soon as possible.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, this is a known issue: on Chinese Windows, Agent Write and StrReplace can write files in GBK instead of UTF-8. In chat the content looks fine, but on disk it turns into garbled text. The bug is tracked, but I can’t share an ETA for a fix yet. I linked your report as another data point for 3.2.11.

A deeper investigation and a workaround are in this thread: Agent Write/StrReplace tools output GBK-encoded files on Chinese Windows — persists in 3.0.13 even after ACP changed to 65001

What you can do for now:

  • Use the Python script to fix already corrupted files (in the post above, it detects GBK and re-saves as UTF-8).
  • Try creating a clean workspace with no existing GBK files. The encoding resolver for new files looks at the majority encoding in the workspace. If there are already GBK files there, it’ll keep writing new ones as GBK too, so it becomes a self-reinforcing loop.
  • Changing the system ACP to 65001 doesn’t help, this is confirmed. The encoding is picked by heuristics from the content, not by the code page.

Once there’s an update on the fix, I’ll reply in that thread.