When copying Chinese text from OpenCode on Cursor IDE’s integrated terminal, the clipboard content is corrupted. UTF-8 encoded characters are misinterpreted as Latin-1/CP1252, producing mojibake.
Only happens in the latest version of Cursor IDE.
Steps to Reproduce
Open Cursor’s integrated terminal, launch Opencode.
Run a command that outputs Chinese text, e.g. echo “附录审稿意见修改报告”(report for appendix review opinions)
Select and copy the output in the terminal
Paste into any text editor or back into the terminal
Copied text should preserve its original UTF-8 encoding.
P.S.: I am running Opencode on a remote server on Cursor IDE via SSH. The garbled characters only happen on Cursor IDE. Using Powershell works fine.
Hey, thanks for the detailed report. The repro steps and version info are exactly what we need.
This sounds like a classic issue where UTF-8 bytes get treated as Windows-1252 when copying from the terminal buffer. One question to narrow it down:
Does this also happen with normal terminal output, without OpenCode or a TUI? For example, just run echo "附录审稿意见修改报告" in a shell session (you can do it right on the remote host over SSH), then select and copy it. I want to figure out if this is an xterm.js issue, or if it’s about how the TUI renders CJK over SSH.
Let me know what you get, and I’ll know where to dig next.
Hey, thanks for the update, and for clearly narrowing it down (TUI + a shell session in Cursor’s terminal over SSH).
We’re still tracking this bug on our side. Updating to 3.7.27 didn’t fix it, which is expected. Based on your tests, it’s not version-specific, it’s about how Cursor’s terminal handles clipboard data from TUI apps. Tools like OpenCode write to the clipboard via OSC 52, and the UTF-8 gets corrupted there. We’ve also got another thread with the same symptom from tmux, so the pattern is clear to us.
I can’t share a fix timeline yet. As soon as there’s an update, I’ll post it here.
As a temporary workaround, copying the same text from a regular shell session (without a TUI) in Cursor’s terminal works correctly, as you noticed.
Good to hear from you, and glad to hear that you have located the problem source. Take it easy since Cursor is still working (grateful it still supports CentOS7), and hope to see the problem can be solved once and for all in the furture update!
When I select Japanese text displayed in the integrated terminal and copy it
(mouse selection + Ctrl+C or right-click copy), the text placed on the clipboard
is corrupted. The UTF-8 byte sequence appears to be re-decoded as CP1252/Latin-1,
so every Japanese character turns into 2-3 Western accented characters.
Example: the string “RENTAI HOSHO” written in kanji (U+9023 U+5E2F U+4FDD U+8A3C)
becomes: e f a c a a e e c (CP1252 mojibake like “e a” accented letters)
Pasting into ANY app (LINE, Gmail, X, or back into the terminal input itself)
shows the same corrupted result, so the corruption happens at copy time,
not paste time.
ASCII-only text copies fine. Only non-ASCII (Japanese, and presumably all CJK)
is corrupted.
What I verified (isolation tests)
Windows system locale is ja-JP, ANSI codepage 932 (so this is NOT the OS
ANSI conversion – that would produce Shift-JIS-style mojibake, not CP1252-style)
No custom encoding settings: files.encoding / autoGuessEncoding are defaults
Writing the same Japanese string to the clipboard via PowerShell Set-Clipboard
and pasting into the same target apps works perfectly → clipboard and target
apps are fine
Copying the same Japanese string from the terminal selection is corrupted 100%
of the time
Steps to Reproduce
On Windows (Japanese locale), open the integrated terminal
Print any Japanese text, e.g.: echo “test JAPANESE-TEXT-HERE 12345”
Select the output line with the mouse and press Ctrl+C (or right-click copy)
Paste anywhere (another app or the terminal input)
Expected: the selected text is pasted as-is
Actual: every non-ASCII character is replaced by CP1252 mojibake
Operating System
Windows 10/11
Version Information
Cursor version: 3.12.10
OS: Windows 11 Home 10.0.26200
System locale: ja-JP (ACP 932)
Shell: PowerShell 5.1 / Git Bash (happens with both)
Glad to hear that! However, I have to stay at v3.9 because my remote server runs on CentOS 7, which is not supported after Cursor v3.10.
Thanks for your work again and wish to see more features in future versions.
