After the file is written to the workspace, the actual file content becomes garbled

[MINGCHEN]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When using the Agent to create new code files, everything looks correct in the chat output (Chinese characters display normally). However, after the file is written to the workspace, the actual file content becomes garbled.

Steps to Reproduce

My workspace is configured to use UTF-8 encoding.
Use the Agent to create new code files(including chinese).
The newly generated file will contain unreadable characters.
To read the file correctly, I have to open it using GBK encoding and then manually re-save it as UTF-8.
It seems that the Agent is writing files using GBK encoding instead of UTF-8, despite the workspace being configured for UTF-8.

Expected Behavior

The Agent should always write files using UTF-8 encoding, consistent with the workspace encoding. Chinese characters should be correctly preserved without requiring manual re-encoding.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.1.14 (user setup)
VSCode Version: 1.105.1
Commit: d8673fb56ba50fda33ad78382000b519bb8acb70
Date: 2026-04-14T01:39:23.679Z
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

3e6bae18-8b10-4626-b5fc-e0135ae057ce

Does this stop you from using Cursor

No - Cursor works, but with this issue

[suchangche (逸 龙)]

same

[MINGCHEN]

Hundreds of files contain unreadable characters, which is extremely annoying

[deanrie]

Hey, thanks for the report. This is a known encoding issue on Chinese Windows. Agent Write and StrReplace create files in GBK instead of UTF-8.

Root cause: the auto-detect encoding logic picks up GBK from the system environment or existing files and then propagates it to new files, even if the workspace is set to UTF-8.

Temporary workaround while it gets fixed:

• Reopen the file explicitly with GBK encoding: File > Reopen with Encoding > GBK
• Use Save As and pick UTF-8 encoding

Related reports:

• Agent Write/StrReplace tools output GBK-encoded files on Chinese Windows — persists in 3.0.13 even after ACP changed to 65001
• Subject: StrReplace Tool Corrupting UTF-8 Characters

The bug is logged, and your report helps raise the priority. Let me know if you notice any patterns for when it happens or does not happen. That would help the team.