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

Support Bug Reports
, ,
70

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.

71

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.

72

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.

76

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.

79

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

81

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

83

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.