Why do files generated by Cursor constantly have encoding issues? It’s extremely frustrating. Is the Cursor team working on fixing this?

[deanrie]

This is a known bug with the agent Write and StrReplace tools. If the tool-call arguments include non-ASCII characters, the file gets written with the wrong encoding on some systems, like on Chinese Windows it uses GBK instead of UTF-8. Users with Chinese, Korean, Japanese, and Turkish locales can reproduce it.

We’ve logged the issue and we’re tracking it, but I can’t share an ETA for a fix yet. Version 3.0.12 is fairly old, but the bug is still present in recent builds too, so updating alone won’t help.

A few related threads with discussion and temporary workarounds:

• Spending tokens to repair UTF-16 that should have been UTF-8
• Agent Write/StrReplace tools encode non-ASCII content as GBK on disk despite files.encoding=utf8
• Agent Write/StrReplace tools output GBK-encoded files on Chinese Windows — persists in 3.0.13 even after ACP changed to 65001