Agent Write tool creates new files as BOM-less UTF-16LE on Windows, breaking C# compilation

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Files CREATED by the agent’s Write tool are written as UTF-16LE with no BOM. Because there’s no BOM, the C# compiler treats them as UTF-8 and fails with CS1056 Unexpected character ‘\0’. Files EDITED retain their existing encoding.

According to the AI, the Agent shell is pinned to C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe (Windows PowerShell 5.1 / PSEdition Desktop).

Setting terminal.integrated.defaultProfile.windows and automationProfile.windows to pwsh 7, restarting Cursor, and configuring PS 5.1 for UTF-8 all had no effect — the agent shell stays on 5.1 and output stays BOM-less UTF-16, indicating the encoding comes from the backend file-writer, not the shell. BOM-less UTF-16 isn’t produced by any default PowerShell cmdlet (Out-File adds a BOM; Set-Content is ANSI), which further points to the backend.

Steps to Reproduce

On a Windows machine whose agent shell is Windows PowerShell 5.1, ask the agent to create a new text/.cs file.
Inspect the raw bytes: they start with 68 00 65 00 … (UTF-16LE, no FF FE BOM).

Expected Behavior

Expected: New files written as UTF-8 (no BOM), or at minimum UTF-16 with a BOM so the compiler detects it.

Operating System

Windows 10/11

Version Information

Version: 3.12.29 (user setup)
VS Code Extension API: 1.128.0
Commit: cd1c87ff9b66021918fb9731605f8d1d5fd2f0b0
Date: 2026-07-21T03:26:05.811Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

Additional Information

Notes / ruled out: Not caused by git (core.autocrlf only affects line endings), no repo .editorconfig/.gitattributes, files.encoding unset (defaults UTF-8).

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Thanks for the detailed report. I’ve confirmed this is a known bug in the Agent’s file-writing path on Windows, and I’ve linked your report to our investigation.

For now, the safest workaround is to create new files using a command that explicitly writes UTF-8 rather than the Write tool. We’ll update this post with any updates!

8

Any ETA on the update?

The cost of tokens is slowly skyrocketing with new models, and it’s a serious disservice to your users that this bug has been present for so long.

I’m having it in almost every single file update lately, making it incredibly frustrating.