Cursor integrated terminal corrupts UTF-8 OSC 52 clipboard text from tmux

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Integrated Terminal OSC 52 Clipboard UTF-8 Bug

Summary

Cursor’s integrated terminal appears to mishandle OSC 52 clipboard payloads containing UTF-8 text from tmux. Copying Chinese text from tmux copy-mode produces mojibake such as 中文 instead of 中文.

The same workflow works correctly in VS Code.

Environment

  • OS: macOS 26.4
  • Cursor: 3.6.21
  • tmux: 3.6b
  • Shell locale: UTF-8
  • Terminal: Cursor integrated terminal

Minimal Reproduction

Start a clean tmux server in Cursor’s integrated terminal:

tmux -L repro -f /dev/null new -s repro

Inside tmux:

:set -g mouse on

Then run:

printf '中文复制探针ABC\n'

Use the mouse to drag-select the Chinese text in tmux. Paste the clipboard content elsewhere.

Expected Result

中文复制探针ABC

Actual Result

Chinese text is pasted as mojibake, for example:

中文

Diagnosis

The tmux paste buffer contains the correct UTF-8 text. macOS clipboard APIs also handle Chinese text correctly when using pbcopy and pbpaste directly.

The corrupted clipboard content has the shape of UTF-8 bytes interpreted as Latin-1 and then encoded as UTF-8 again.

For example, 中文 in UTF-8 is:

e4 b8 ad e6 96 87

After copying through Cursor’s integrated terminal OSC 52 path, the clipboard contains bytes corresponding to 中文:

c3 a4 c2 b8 c2 ad c3 a6 c2 96 c2 87

This suggests the OSC 52 base64 payload is decoded as a binary/Latin-1 string instead of being decoded as UTF-8 text.

Workaround

On local macOS tmux, disabling OSC 52 and piping copy-mode selections through pbcopy avoids the issue:

set -g set-clipboard off
bind-key -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel 'pbcopy'
bind-key -T copy-mode MouseDragEnd1Pane send-keys -X copy-pipe-and-cancel 'pbcopy'

This workaround does not solve remote SSH tmux workflows, where the remote tmux normally relies on OSC 52 to write to the local clipboard.

Impact

This breaks copying non-ASCII text from tmux when using Cursor’s integrated terminal, especially in remote development workflows where OSC 52 is the normal clipboard bridge.

Steps to Reproduce

Start a clean tmux server in Cursor’s integrated terminal:

tmux -L repro -f /dev/null new -s repro

Inside tmux:

:set -g mouse on

Then run:

printf '中文复制探针ABC\n'

Use the mouse to drag-select the Chinese text in tmux. Paste the clipboard content elsewhere.

Operating System

MacOS

Version Information

  • OS: macOS 26.4
  • Cursor: 3.6.21
  • tmux: 3.6b
  • Shell locale: UTF-8
  • Terminal: Cursor integrated terminal

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the report, and extra thanks for the deep dive. Isolating the OSC 52 path and comparing the bytes really helps.

This is a known bug on our side. When copying non ASCII text like CJK through the terminal, it ends up as double encoded mojibake. This doesn’t happen in VS Code. I’ve filed an internal report that the OSC 52 path is affected too, not just normal selection. I can’t share a fix timeline yet.

Your workaround using set-clipboard off plus copy-pipe with pbcopy is a good temporary fix for local tmux. For remote SSH, where OSC 52 is the main bridge to the clipboard, we don’t have a workaround yet.

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

7

Related observation on Cursor 3.9.16 (macOS 15.7.4, zsh, no tmux) — may widen the same clipboard/selection surface Dean flagged here.

What matches this thread

  • Corruption happens on copy-out from Cursor’s integrated terminal (mouse-drag select → Cmd+C → paste elsewhere).
  • Non-ASCII / TUI chrome becomes classic mojibake (box-drawing from Claude Code’s UI pastes as ▐▛…-style garbage).
  • Same text is fine if it never goes through terminal selection (write to a file / in-session extract; pbcopy/pbpaste round-trips of known payloads are clean).

What’s broader than the OP’s CJK/tmux case

  1. No tmux / no OSC 52 from tmux in my setup — just Claude Code (Ink TUI) running in Cursor’s integrated terminal.
  2. Alongside mojibake, I also see mid-word ASCII drops in the same copies (e.g. NEVER assume… → NEVERnges, paths/words truncated mid-token). Paste still arrives; it’s silently mangled, not an empty clipboard / “no selection to copy” toast.
  3. I instrumented the opposite direction tonight and could not reproduce the separate ~1018-byte paste-in truncation reports: known ASCII payloads at 1018 (bare zsh) and 3000 (into Claude Code) were byte+SHA-256 identical. So on 3.9.16 / bundled node-pty 1.1.0-beta42 this looks like a selection/copy-out problem, not paste-in.

Minimal repro (no tmux)

  1. Cursor integrated terminal → run claude.
  2. Produce a long reply (or print a long ASCII marker block).
  3. Mouse-drag select the output → Cmd+C.
  4. Paste into TextEdit / another app.
  5. Observe: mojibake on Unicode/TUI chrome and/or mid-word ASCII drops.
  6. Control: have the agent write the same text to a file and open the file — content stays clean.

Happy to run any extra probes (Shift+drag native select vs normal select, pbpaste | shasum right after copy, etc.) if useful for the internal report. Main ask: please treat this as evidence the clipboard corruption isn’t limited to tmux OSC 52 + CJK — plain Claude Code selection in the integrated terminal hits it too, including ASCII mangling.

8

Hey Brandon, thanks for the detailed write-up, especially for isolating the no-tmux and no-OSC52 case.

I can confirm the mojibake on copy-out part. It’s the same known encoding bug on our side, and you’re right that it’s not limited to tmux plus OSC 52. The normal selection-copy path from the integrated terminal can hit it too, Claude Code Ink TUI is a good example. It’s already logged, and we don’t have an ETA for a fix yet. I’ll add your note that this is broader than tmux to the internal report.

The mid-word ASCII drops (NEVER assume… → NEVERnges) look like a separate issue. This isn’t about encoding, it’s silent character loss. So it doesn’t get mixed with the encoding bug and we can track it cleanly, please start a separate thread for that symptom. What to include:

  • The exact deterministic ASCII marker block you copy, so it’s easy to reproduce
  • Before and after at the byte level or a SHA-256 (pbpaste | shasum) right after copy
  • Whether behavior differs between native Shift+drag select vs the usual select in the terminal

With that repro, we should be able to reproduce it internally and debug it separately.

Also helpful that you couldn’t reproduce the paste-in truncation at around 1 018 bytes on 3.9.16. That’s a separate paste-in issue, so no need to worry about it here.

If I get an update on the encoding fix, I’ll reply in the thread.

10

Hey there!

A fix for this is coming in v3.14. Thanks again for the report.

11

Glad to hear it. Thanks for letting me know