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.