Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Where does the bug appear (feature/product)?
Cursor IDE — Agent tool Write (create/overwrite file). In this session StrReplace on existing UTF-8 files was fine; Write of new .md files was not.
Describe the Bug
On macOS, with locale C.UTF-8, the Agent Write tool persists Polish text as Windows-1252 with errors=‘replace’, not UTF-8.
Characters outside CP1252 (ą ć ę ł ń ś ź ż and uppercase) become a literal ASCII ? (0x3F). That is irreversible data loss.
Characters inside CP1252 (ó, em dash — U+2014) are stored as raw CP1252 bytes (0xF3, 0x97). The file is then invalid UTF-8.
The model’s tool-call payload is correct Unicode. Chat shows the right letters. The corruption happens on the write-to-disk path.
This matches the ASCII-replacement variant already noted for CreatePlan (sincroniza??o), plus leftover CP1252 bytes, so file(1) reports charset=unknown-8bit.
Steps to Reproduce
Steps to Reproduce
macOS (Darwin 25.5.0 arm64), Cursor 3.16.17, locale C.UTF-8. No files.encoding / .editorconfig in the workspace.
Workspace also contains Windows-origin binary docs (PDF/DOCX) in a SOURCES/ folder — possible trigger for the “sniff nearby files” behaviour.
Ask the Agent to create a new .md file with the Write tool containing:
Udostępnione oferty — protokół. Zażółć gęślą jaźń.
Inspect bytes on disk (xxd / Python). Control: write the same string via
python3 -c “open(‘t.md’,‘w’,encoding=‘utf-8’).write(‘…’)”
→ correct UTF-8 (ę = C4 99, — = E2 80 94).
Observed bytes (this incident)
First line written by Write:
23 20 55 64 6f 73 74 3f 70 6e 69 6f 6e 65 20 6f 66 65 72 74 79 20 31 37 2e 30 38 2e 32 30 32 36 20 97 20 70 75 6e 6b 74 61 63 6a 61 …
i.e. # Udost?pnione oferty 17.08.2026 <0x97> punktacja…
Decoded as cp1252 the 0x97 is an em dash; ę is already gone (3F).
Same content rewritten through open(…, encoding=“utf-8”) in the terminal:
23 20 55 64 6f 73 74 c4 99 70 6e 69 6f 6e 65 … e2 80 94 …
check-encoding.py then reports 0 errors; file -I reports charset=utf-8.
In one Write batch, three new files were corrupted the same way (~168 ? in one file). StrReplace patches to other UTF-8 files in the same turn kept Polish letters.
Expected Behavior
Expected Behavior
Agent Write / StrReplace must always encode UTF-8 (no BOM) unless the existing file on disk is a different encoding that is being preserved. Never encode(cp1252, errors=‘replace’). Never infer charset from neighbouring PDF/DOCX. Honor files.encoding / .editorconfig. Unmappable characters must not become ?.
Operating System
MacOS
Version Information
macOS 15.5 (Darwin 25.5.0) arm64 — not Windows. LANG=C.UTF-8. System ACP is not 1252. This is a useful counterexample to “Windows-only / ACP” explanations.
Version Information
Cursor: 3.16.17 (stable)
Commit: 6b2afae0257df2bb5e1835f15165dc2f0de056b0
OS: Darwin 25.5.0 arm64
For AI issues: which model did you use?
Not model-specific (reproduced with Agent Write regardless of the chat model). Same class of bug as forum threads below.
Additional Information
Additional Information
Related, same root cause (Cursor staff, Dean Rie):
Encoding errors on new files — write tool sniffs nearby files, re-encodes to 1252/GBK/UTF-16; files.encoding ignored.
Why does Cursor sometimes convert Chinese text to question marks, and why does this issue persist in the same file once it occurs—every time I modify that file, the Chinese characters get turned into "?" again? — ? replacement; encoding sticks to the file.
CreatePlan ? variant: sincroniza??o, 0x3F, zero UTF-8 multibyte sequences.
Workaround that worked here: do not use Write; persist via terminal python3 / open(…, encoding=“utf-8”). That is not acceptable as a product fix (Cursor staff already agreed).
Hypothesis to test: this workspace’s SOURCES/ is full of Windows-produced PDF/DOCX. If sniffing is real, an empty UTF-8-only workspace should not reproduce; a folder next to .docx/.pdf should.
Does this stop you from using Cursor
No - Cursor works, but with this issue