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.
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.
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.
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.
