Subject: StrReplace Tool Corrupting UTF-8 Characters

Support Bug Reports
,
1

CURSOR Team,

Your product is absolute garbage! I used your StrReplace tool on Windows 10, and it completely ruined my PHP file like this:

“??? ? ??�??�??�BJ ?? ???”

This is an utter waste of my time! The tool failed to preserve the UTF-8 encoding and instead rewrote the entire file in Windows-1252 (ANSI), turning all my Korean, Japanese, and Chinese characters into “?” (0x3F), completely destroying the data! This is not a tool, it’s a bug bomb!

Your product is getting more unreliable by the day. It’s completely untrustworthy and severely impacts my work! I’ve wasted days of my time, and the money spent is completely wasted! Your tool is so unstable, it shouldn’t even be on the market.

I demand that you fix this issue immediately and provide a compensation plan. Otherwise, I’ll never use your product again! I expect you to resolve this problem quickly.

ID: a4392bf5-95ef-4102-86f1-8f597e3699af
Model: Sonnet 4.6

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

4

How could something this idiotic even exist? You’ve completely wasted my time, and the money I’ve spent on this product is a total joke! This tool has no business being out in the market — it’s beyond unreliable and causing irreversible damage to my work.

6

Hey, this is a known issue with encoding when editing files via agent/StrReplace on Windows. The team is aware, and a few fixes have already shipped in recent versions.

A couple questions so we can understand what’s happening:

  1. What Cursor version are you on? Menu → About Cursor → Copy
  2. Was the file originally UTF-8, and after StrReplace the encoding changed to Windows-1252? Or was the file in a different encoding to begin with?

Similar reports from other users:

For now, I’d recommend using git to revert any corrupted files git checkout -- <file> and making sure you’re on the latest Cursor version since a few encoding fixes have already been released.

Also, I get that data loss is really frustrating, but constructive bug reports help us investigate faster. The template from the system message above is exactly what we need for an effective investigation.

7

Listen, I just downloaded the latest version of CURSOR a few days ago, and I’m still dealing with the same issue. The file was originally UTF-8, and after using StrReplace, it was completely re-encoded to Windows-1252. How is this still happening? You guys are aware of this problem, but nothing has been fixed!

9

Got it, so the issue also reproduces on the latest version.

The team is aware of the Windows encoding issue, I shared your case since it adds more context around CJK characters specifically.

For now, the best workaround is to use git to restore the corrupted files:

git checkout -- <path-to-file>

Or if you are not using git, make a backup of the files before agent sessions that include CJK content.

12

This is not a minor issue — it caused real data loss and wasted several days of my time.

Saying “we’re aware” is not enough. I paid for this product and got a broken tool.

I expect a clear explanation, a fix timeline, and proper compensation.

13

I’ve had this problem for the past two or three weeks. It changes characters to CP1215/Unicode, and then I have to waste tokens again to get it to correct to pure UTF-8.
Version: 3.5.38
VSCode Version: 1.105.1
Commit: 009bb5a3600dd98fe1c1f25798f767f686e14750
Date: 2026-05-26T21:32:06.537Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.0-29-generic

14

Hey, thanks for the report and for the detailed version, it helps.

This is a known bug. When editing via the agent Write or StrReplace, the original UTF-8 encoding isn’t always preserved, and non-ASCII characters like CJK can get corrupted. It reproduces on multiple platforms, including Linux. We’re tracking the issue, but I can’t share an exact fix timeline yet.

Workaround for now:

  • If the files are in git, revert the damaged ones with git checkout -- <path>.
  • If you’re not using git, back up files with CJK content before agent sessions.

Once there’s an update on the fix, I’ll reply in this thread.