Feature request
When Claude Code copies text via OSC 52, it should write to both the c (CLIPBOARD) and p (PRIMARY) X11 selections, not just CLIPBOARD.
Background
The TUI captures mouse events and copies selected text via OSC 52 to CLIPBOARD. This is actually an improvement over letting the terminal emulator handle selection natively — the TUI has two empty margin columns on the left, and a native X selection would include those as two spurious leading spaces on every line. OSC 52 copies the actual content cleanly.
However, on X11 the middle mouse button pastes from PRIMARY, not CLIPBOARD. So the current flow breaks the standard X workflow:
select text → middle-click to paste
because the selection lands in CLIPBOARD while middle-click reads PRIMARY.
Proposed fix
OSC 52 supports specifying the target selection in the Pc parameter:
ESC ] 52 ; c ; <base64> ST ← writes CLIPBOARD (current behaviour)
ESC ] 52 ; p ; <base64> ST ← writes PRIMARY
Sending both sequences when copying would make middle-click paste work naturally with no change to the user's terminal or workflow, while keeping the clean content (no margin padding) that OSC 52 already provides.
Workaround
Running autocutsel -fork (syncs PRIMARY↔CLIPBOARD automatically) works around the issue on the user side, but requires an extra daemon and affects all applications.
Environment
- Linux / X11
- xterm-compatible terminal
- Claude Code CLI
Feature request
When Claude Code copies text via OSC 52, it should write to both the
c(CLIPBOARD) andp(PRIMARY) X11 selections, not just CLIPBOARD.Background
The TUI captures mouse events and copies selected text via OSC 52 to CLIPBOARD. This is actually an improvement over letting the terminal emulator handle selection natively — the TUI has two empty margin columns on the left, and a native X selection would include those as two spurious leading spaces on every line. OSC 52 copies the actual content cleanly.
However, on X11 the middle mouse button pastes from PRIMARY, not CLIPBOARD. So the current flow breaks the standard X workflow:
select text → middle-click to paste
because the selection lands in CLIPBOARD while middle-click reads PRIMARY.
Proposed fix
OSC 52 supports specifying the target selection in the
Pcparameter:Sending both sequences when copying would make middle-click paste work naturally with no change to the user's terminal or workflow, while keeping the clean content (no margin padding) that OSC 52 already provides.
Workaround
Running
autocutsel -fork(syncs PRIMARY↔CLIPBOARD automatically) works around the issue on the user side, but requires an extra daemon and affects all applications.Environment