Terminal OSC 52 clipboard corrupts multi-byte UTF-8 (CJK/Cyrillic/emoji) — fixed upstream in VS Code 1.125, Cursor still ships the buggy addon

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Copying text that an app in the integrated terminal places on the clipboard via OSC 52 (e.g. Claude Code’s TUI mouse selection) corrupts all multi-byte UTF-8: Chinese/Cyrillic/emoji become Latin-1 mojibake (e.g. 要 → è¦), while ASCII in the same selection is preserved.

Root cause: @xterm/[email protected] decodes the OSC 52 base64 payload with bare atob() and writes the resulting Latin-1 binary string to the clipboard without a UTF-8 decode. This regression shipped in VS Code 1.123/1.124 and was fixed upstream:

  • xtermjs/xterm.js#6002
  • microsoft/vscode#320646 (released in VS Code 1.125)

Repro:

  1. Cursor 3.12.30 (macOS arm64) → Remote-SSH to a Linux host (also reproduces inside tmux).
  2. Run any app that copies via OSC 52 — e.g. Claude Code, select non-ASCII text in its TUI with the mouse.
  3. Paste: multi-byte characters are mojibake, ASCII is intact.

Cross-check that isolates this to Cursor: official VS Code 1.130.0 connected to the same host over Remote-SSH copies the same text correctly.

Cursor’s About panel reports the identical xterm.js: 6.1.0-beta.256 across several recent releases (3.11.x → 3.12.30), which suggests the terminal stack (including @xterm/addon-clipboard) is pinned and hasn’t absorbed the upstream fix despite the VS Code API 1.128 rebase.

Ask: please bump the bundled @xterm/addon-clipboard to a version containing the xterm.js#6002 fix.

Also tracked from the app side at anthropics/claude-code#66098 (labeled external there, since the sender encodes correctly).

Environment:

  • Cursor 3.12.30 (Universal), commit 63a2996a10d9e476b6c28e951dd7691d9c0cf480, macOS Darwin arm64 25.5.0
  • Remote-SSH to Linux (Ubuntu, tmux 3.x), reproduces with and without tmux
  • xterm.js: 6.1.0-beta.256, Electron 40.10.3

Steps to Reproduce

  1. Cursor 3.12.30 (macOS arm64) → Remote-SSH to a Linux host (also reproduces inside tmux).
  2. Run any app that copies via OSC 52 — e.g. Claude Code, select non-ASCII text in its TUI with the mouse.
  3. Paste: multi-byte characters are mojibake, ASCII is intact.

Operating System

MacOS

Version Information

  • Cursor 3.12.30 (Universal), commit 63a2996a10d9e476b6c28e951dd7691d9c0cf480, macOS Darwin arm64 25.5.0
  • Remote-SSH to Linux (Ubuntu, tmux 3.x), reproduces with and without tmux
  • xterm.js: 6.1.0-beta.256, Electron 40.10.3

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Thanks for the report @Dinghao_Yang! This looks a lot like:

We raised a bug ticket as a part of that first thread, and I’ve gone ahead and linked your report there as well! We’ve also recently bumped this ticket’s priority.

As a temporary workaround, copying the same text from a regular shell session (without a TUI) in Cursor’s terminal should work correctly

8

Hey again!

This was a pretty easy dependency bump, so it should make its way into 3.14. Thanks again for flagging