The cursor generated the plan.md file, but due to encoding issues, it displays unreadable characters

[ge_ge]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

My project uses GBK encoding, and I suspect that Cursor automatically opens existing files with GBK (though I haven’t confirmed this).

Later, I used Cursor to generate a plan.md file. When I opened it, it showed unreadable characters (�����). This suggests that Cursor might be using UTF-8 when generating new files, while reading existing ones as GBK – an inconsistent behavior.

I tried to change the file’s encoding to UTF-8 using the encoding control in the status bar, but for plan.md that control was missing (it is present for ordinary code files).

Since I couldn’t change the encoding directly, I explicitly asked Cursor to regenerate plan.md in GBK format. After reopening it with GBK, the Chinese displayed correctly.

Steps to Reproduce

Open a project where existing files use GBK encoding.
Ask Cursor to generate a new plan.md file.
Open the generated plan.md file in the editor.
The file shows unreadable characters (�����), indicating an encoding mismatch.
For plan.md files, the encoding selection option is missing in the status bar, so it cannot be manually switched to UTF-8.
Regenerate the plan.md file in GBK format — it displays correctly.

Expected Behavior

The plan.md file should display Chinese text correctly when opened. Instead, it shows unreadable characters (�����), and the encoding control is missing for .md files, preventing manual switch to UTF-8.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.7.19 (system setup)
VS Code Extension API: 1.105.1
Commit: 80c653c2c3528e65016a0d304b54486084b470b0
Date: 2026-06-07T01:42:56.126Z
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
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.19045

For AI issues: which model did you use?

auto

For AI issues: add Request ID with privacy disabled

cf0388bc-a4af-4c23-8455-de8ce64936cd

Does this stop you from using Cursor

No - Cursor works, but with this issue

[Tom_Coustols]

hey @ge_ge, this seems like a known issue being actively watched by the team!

It’s about the Chinese garbled text issue in the source code generated by the Cursor editor, can you take a look and fix it?

Key takeaway: it has nothing to do with the file extension. Earlier cursorAgentEditExtractor.ts was UTF-8 only because it was later rewritten by StrReplace and went through a different write path. The real reason is that when the Cursor agent creates new files, its write path uses GBK/CP936 encoding for the zh-CN locale and ignores all files.encoding settings. This is Cursor-side behavior and there’s no config switch to change it. So trying to fix it via settings just won’t work. That’s the co…

[deanrie]

Hey, thanks for the detailed report with the screenshot and the Request ID. There are two separate things here.

1. Garbled text. This is a known bug. The agent Write and StrReplace tools save files as UTF-8 and don’t respect the project encoding, in your case GBK, so the new plan.md opens as �����. This has been reported and is being tracked, but I can’t share a specific ETA for a fix yet. There are already a lot of similar threads, for example It’s about the Chinese garbled text issue in the source code generated by the Cursor editor, can you take a look and fix it?.

2. No encoding selector for .md. This is by design. .md files open in a custom rich-text Markdown editor that doesn’t have the standard encoding control in the status bar. To get the selector back, right click the file tab and choose Open With… then Text Editor, or use the Command Palette Ctrl+Shift+P then Change File Encoding.

As a workaround for now, your approach is fine. Explicitly ask the agent to generate the file in GBK. Let me know if any of this doesn’t work.

[jlbgit]

Hi,

Same issue here, no matter which model, markdown files and plans are produced with encoding issues - the agent says:

“”"
One thing to flag

The Write/edit tooling here silently saved non‑ASCII as broken cp1252 (accents/dashes got mangled, some lossily). I detected it, discarded that version, and rewrote the whole file through a UTF‑8‑safe path — file now confirms valid UTF‑8 and the accents render correctly.
“”"

I even added a rule to always write UTF-8, but this didn’t fix it.

Thanks

[deanrie]

Hey. This is the same known bug as in that thread. The agent’s Write and StrReplace tools can corrupt non-ASCII content when saving. In your case it gets mangled into cp1252 or Windows-1252. We’re tracking the issue, but I can’t share an exact ETA for a fix yet.

Important note: adding a rule like always write UTF-8 won’t help here, and that’s expected. The problem is in the file-writing tool itself, not in the agent’s reasoning, so prompts and rules can’t override it.

Workarounds you can use right now:

• After the file is generated, right-click the tab, pick Open With… then Text Editor, then open Command Palette with Ctrl+Shift+P, run Change File Encoding, and save again with the encoding you need.
• Or ask the agent to regenerate the file in the target encoding like the OP did. It’s not 100% reliable, but it often works.

Once there’s an update on the fix, I’ll post it in the thread.