Unicode on Windows is glitching

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Bug: file-read tool decodes UTF-8 files as CP1251 (Windows), and edits round-trip lossily

Environment: Cursor on Windows 10 (win32 10.0.19045), PowerShell shell, repo with UTF-8 files
containing em dashes and Cyrillic text.

What happens

The agent’s file-read tool mis-decodes UTF-8 file content as CP1251 (Windows-1251). Every
non-ASCII character reaches the model as mojibake:

  • — (U+2014, UTF-8 E2 80 94) is presented as —
  • Заголовок is presented as Заголовок

The same wrong decoding appears in the search tool’s content output and in the terminal-output
files the agent reads. Notably, the shell’s own stdout decodes correctly — git log printed
the same em dashes properly in the same session — so it is specific to the file-read path.

Why it’s harmful

  1. The model cannot see the real content, and it quotes the mojibake back to the user, which
    looks like the model corrupted something.
  2. The write path is lossy. Because the model is shown —, it reproduces — in an edit’s
    replacement text; what actually lands on disk is a plain ASCII -. So an edit silently
    downgrades characters it never intended to touch, and the file ends up with inconsistent
    punctuation. Exact-match replacement of untouched text does round-trip, which makes the
    damage easy to miss.
  3. There is no workaround at the tool level: the read tool takes only path / offset /
    limit, with no encoding parameter. The only escape is reading files through the shell
    (Get-Content -Encoding UTF8), which the tool guidance explicitly discourages.

Steps to Reproduce

Repro

  1. On a Windows machine whose system ANSI codepage is 1251, create a UTF-8 file containing
    a — b.
  2. Ask the agent to read it: it reports a вЂ" b.
  3. Ask the agent to edit that line: the written result contains a - b.

Expected Behavior

Expected

Decode file bytes as UTF-8 (with BOM detection and a sane fallback), independent of the Windows
system ANSI codepage, and encode edits back as UTF-8. Optionally expose an encoding override.

Operating System

Windows 10/11

Version Information

3.14.27 (user setup)

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Hey @dimskraft ,

To unblock:

  1. Set "files.encoding": "utf8" and "files.autoGuessEncoding": false.
  2. Open an affected file; if the bottom-right status bar isn’t UTF-8, click it → Reopen with Encoding → UTF-8.
  3. Restart Cursor (clears the per-file encoding cache so edits don’t write the wrong encoding back).
  4. After an edit, confirm the file is still UTF-8 on disk (git diff or a quick hex check) until the status bar shows UTF-8 everywhere.

If the status bar already shows UTF-8 but the agent still sees mojibake, that’s a different trigger - send your current files.encoding / files.autoGuessEncoding values plus a hex dump of one affected line and I’ll dig in.