Spending tokens to repair UTF-16 that should have been UTF-8

Hola, misma falla terrible en Sur America.

He intentado varias soluciones durante meses hasta que al fin descubro que es un bug de CURSOR IDE.

Vamos, por favor solucionarlo! Es una perdida absoluta de tiempo, porque a veces la información se corrompe a tal grado de importancia que definitivamente se pierde y no se puede solucionar con un simple script de vuelta a UTF-8. Además puede corromper archivos sanos del pasado. ES UNA LOCURA, UN DESASTRE!

Intenté muchos parches, ninguno funcionó!!!

Saludos desde Sur America. Por favor reportarlo con urgencia al área de investigación.

I just updated to the latest version of Cursor (3.9.16) and it is seemingly worse. It was better with all of the posted workarounds prior to updating, only happening a few times an hour, but now almost every single prompt requires me to use more tokens to fix the utf-16 files.

Seriously considering alternatives like Codex or Claude at this point.

Seriously considering alternatives like Codex or Claude at this point.

Same here. Cursor is not taking this seriously. All the time that must have been spent to provide this latest update - Cursor Now Available on IOS! - but the basic product STILL does not work properly after months of users losing time, money and work. Priorities are in the wrong place.

Still no fix date I can share. The write-path encoding bug remains open and high-priority on our end. We already have byte-level evidence (existing-file edits landing as UTF-16 LE), so we’re not asking for more recordings on the core bug.

If a file is already UTF-16 LE, recover from the status bar: Reopen with Encoding → UTF-16 LE, then Save with Encoding → UTF-8. The video ask earlier was only for the separate mass re-save path (one edit rescanning thousands of files), not this core bug. Scope any encoding hook to the changed file only. We’ll post here when a fix ships.

Where in God’s name is the fix already? Going on four months!

Still wasting tokens on that. I’m thinking about pausing my subscription until its fixed.

Thanks for bearing with this, and I’m sorry it’s still eating into your time.

Honest status: this is still an open issue we’re tracking, and I don’t have a fix date I can share yet. I’ll post here the moment one ships.

While it’s pending, this is the most reliable setup to stop losing prompts to it:

  1. New files: have the agent create them through the terminal rather than the Write tool. A short rule like “create new script files by writing them via the terminal, not the Write tool” makes it stick.
  2. Post-edit hook scoped to the changed file only (not a repo-wide scan), so anything written as UTF-16 gets re-saved as UTF-8 right after the edit.
  3. To recover a file that’s already corrupted: click the encoding indicator in the bottom-right status bar → Reopen with Encoding → UTF-16 LE (it renders correctly), then click it again → Save with Encoding → UTF-8. The content is fully recoverable, so nothing is lost — commit first if you’re batch-fixing.

If you’re still getting hit every prompt even with new files going through the terminal, reply with your Cursor version and I’ll look into your specific case.

Not gonna lie, this one is nuts… This was after my agents tried to re-encode to utf8

This is getting ridiculous

3.18.9

The Write tool saved new files as UTF-16. I’ll convert those to UTF-8 so the compiler can read them.

Over and over and over again. What is going on? Time to look for an alternative, wasting time and money.

I subsequently built a workaround (it still eats tokens, but it prevent code contamination). Here was my prompt to pull all the information on what i did and the scripts and sequence that i have Cursor run before it saves or commits files:

look up the project’s UTF-8 validation path from the indexes and the scripts/hooks that actually run before save and commit.

I have the hook layout. Next I’ll read the validator, pre-commit/pre-push, and the encoding notebook so the process matches what actually runs.

There is no automatic convert-on-save. Cursor edit hooks that used to rewrite files after save are disabled. Encoding is prevented in the editor and PowerShell, then checked (fail-closed) at commit, push, and CI. Conversion is a separate, explicit --fix / normalizer step.

Incident log: Scripts/Diagnostic Bundle/Documentation/FILE_ENCODING_VIOLATIONS_NOTEBOOK.md. Policy: .cursor/rules/utf8-only-source.mdc.


1. Before save (prevention, not a gate)

These stop new files from landing as UTF-16. They do not scan or rewrite the tree.

Mechanism Path What it does
Workspace editor defaults .vscode/settings.json files.encoding = utf8, files.autoGuessEncoding = false for PowerShell, Python, Markdown, JSON
EditorConfig .editorconfig charset = utf-8
PowerShell session Scripts/Robust Automated Processes/PowerShell/Initialize-Utf8Session.ps1 Console UTF-8; Out-File / Set-Content / Add-Content default to UTF-8, not UTF-16
Profile install (once per clone) Install-RepoGitHooks.ps1 → Install-RepoPowerShellUtf8Defaults.ps1 Dot-sources the session script in CurrentUserAllHosts
Fleet Windows hosts Services/AWS/Scripts/PowerShell/Deploy-Utf8PowerShellProfiles.ps1 Same defaults on EC2

Cursor save-time hook is off. .cursor/hooks.json is "hooks": {}. Enforce-RepoTextUtf8.ps1 still exists under .cursor/hooks/ for manual use, but it is not run on afterFileEdit / postToolUse (Norton was interrupting every pwsh spawn).

If a buffer was already opened as UTF-16, the editor keeps that encoding until you use Save with Encoding → UTF-8.


2. Canonical checker (the one gate that matters)

Scripts/Robust Automated Processes/Python/validate_repo_sources_utf8.py

Detects UTF-16 (BOM or NUL-between-ASCII) and other non-UTF-8. Default scope is all tracked text-like files (.py, .ps1, .mq5, .mqh, .md, .json, .ini, .set, etc.).

Flag When used
--git-staged Pre-commit and ROBUST_GIT_COMMIT
--full-repo (or no mode flag) Pre-push and CI
--fix Rewrite those files as UTF-8 without BOM (manual; review the diff)
--paths REL … One-off cleanup
--policy-sources-only Legacy narrow scan (Scripts/Services/Experts/Include)

Check (no write):

py -3 “Scripts\Robust Automated Processes\Python\validate_repo_sources_utf8.py” --root . --git-staged

py -3 “Scripts\Robust Automated Processes\Python\validate_repo_sources_utf8.py” --root . --full-repo

Fix, then re-check without --fix (must exit 0):

py -3 “Scripts\Robust Automated Processes\Python\validate_repo_sources_utf8.py” --root . --fix --paths “relative\path\file.py”


3. Before commit (hard gate — check only, no auto-fix)

Install once per clone:

pwsh -NoLogo -File “Scripts\Robust Automated Processes\PowerShell\Install-RepoGitHooks.ps1”

That sets core.hooksPath=.githooks.

Layer Script UTF-8 action
Pre-commit .githooks/pre-commit → .githooks/pre-commit.ps1 Runs validate_repo_sources_utf8.py --git-staged. Fails the commit on UTF-16 / invalid UTF-8. Does not convert.
Robust wrappers ROBUST_GIT_ADD.ps1, ROBUST_GIT_COMMIT.ps1 Same staged UTF-8 check before git add / git commit
EA-only helper ROBUST_FILE_ENCODING_VALIDATOR.ps1 + _EncodingValidation.ps1 Test-FileEncoding / Convert-FileToUTF8 for .mq5 / .mqh

Pre-commit also runs PowerShell parse (Assert-StagedPowerShellParses.ps1) and the new-script catalog gate. Those are not encoding converters.

git commit --no-verify skips this. Policy is not to use it.


4. Before push and in CI (full tree)

Layer Script UTF-8 action
Pre-push .githooks/pre-push → .githooks/pre-push.ps1 validate_repo_sources_utf8.py --full-repo
CI .github/workflows/regression-manifest-validate.yml step “UTF-8 policy” Same Python validator on the full checkout

5. How files actually get fixed

Conversion is operator/agent-run, not hook-run. Hooks only refuse the commit.

Tool Use
validate_repo_sources_utf8.py --fix Preferred for known paths or staged files
Scripts/Tools/normalize_repo_text_utf8.py Bulk convert (UTF-16 LE/BE, UTF-8 BOM strip). --dry-run first
Scripts/PowerShell/Run-NormalizeRepoTextUtf8.ps1 PowerShell wrapper around that Python normalizer
Services/AWS/Scripts/PowerShell/_ConvertOneFileToUtf8NoBom.ps1 Single-file rewrite
_EncodingValidation.ps1 → Convert-FileToUTF8 Used by the EA encoding validator

Typical repair:

  1. Convert with --fix or the normalizer
  2. Re-run the validator without --fix (exit 0)
  3. Stage and commit through ROBUST_GIT_* / hooks

Flow in one line

Editor/PS defaults try to write UTF-8 → optional --fix / normalizer if a file is already wrong → pre-commit scans staged text and blocks → pre-push and CI scan the whole tracked tree and block. Nothing in the live Cursor hook path rewrites files on save.

Cursor’s long period of inaction on this fundamental bug is inexcusable. Use your $60 billion to fix it already

I hit the same UTF-16 issue on Windows. Built a small MCP server that writes/edits files as UTF-8 instead of using Agent Write/StrReplace.
GitHub - Pranav-stac/cursor-write-edit-tool: MCP server for UTF-8 safe file writes on Windows (Cursor Agent Write/StrReplace fix) · GitHub
One-click install button in the README. Not perfect (no inline diff, weak revert), but builds stopped breaking.

+1, still reproducing on Cursor 3.24.9 (Windows 11, build 26200, agent shell Windows PowerShell 5.1).
A new file created with the agent Write tool is saved as BOM-less UTF-16LE (70 00 72 00 …).
Workaround in use: rule to create new files via shell as UTF-8, plus an afterFileEdit hook that re-encodes UTF-16 to UTF-8.