What happens
Any TUI that enables mouse reporting (CSI ? 1000 h) takes the click away from xterm.js, so a plain drag in the terminal no longer creates a selection. On the desktop that is annoying; in code-server it removes the last reliable path to the OS clipboard, because the DOM selection is what the browser's own copy relies on — the VS Code copy commands go through an async IPC hop that loses the clipboard user-gesture.
Concretely: with a full-screen TUI running (e.g. Claude Code with tui: fullscreen), users cannot copy terminal text out of the browser at all, unless they know that Shift+drag forces a selection.
Measured
Loaded the exact @xterm/xterm build shipped by code-server (6.1.0-beta.291) standalone and drove it with real mouse events:
| Mouse tracking armed |
plain drag |
Shift + drag |
| none |
selection |
selection |
?1000h ?1006h |
nothing |
selection |
?1000h ?1002h ?1003h ?1006h |
nothing |
selection |
Ask
xterm.js already has the option that solves this — mouseEventsRequireAlt, which keeps tracking armed but only claims the click while a modifier is held. It is not referenced anywhere in the VS Code build that code-server ships, so it stays at its default.
I have opened an upstream request for VS Code to expose it as a terminal setting: microsoft/vscode#330052. Filing here as well because the browser case is materially worse than the desktop one, and because code-server may want to set the option (or surface a preference) ahead of upstream.
At minimum, documenting Shift+drag as the escape hatch in the terminal FAQ would already help.
What happens
Any TUI that enables mouse reporting (
CSI ? 1000 h) takes the click away from xterm.js, so a plain drag in the terminal no longer creates a selection. On the desktop that is annoying; incode-serverit removes the last reliable path to the OS clipboard, because the DOM selection is what the browser's own copy relies on — the VS Code copy commands go through an async IPC hop that loses the clipboard user-gesture.Concretely: with a full-screen TUI running (e.g. Claude Code with
tui: fullscreen), users cannot copy terminal text out of the browser at all, unless they know thatShift+drag forces a selection.Measured
Loaded the exact
@xterm/xtermbuild shipped by code-server (6.1.0-beta.291) standalone and drove it with real mouse events:Shift+ drag?1000h ?1006h?1000h ?1002h ?1003h ?1006hAsk
xterm.js already has the option that solves this —
mouseEventsRequireAlt, which keeps tracking armed but only claims the click while a modifier is held. It is not referenced anywhere in the VS Code build that code-server ships, so it stays at its default.I have opened an upstream request for VS Code to expose it as a terminal setting: microsoft/vscode#330052. Filing here as well because the browser case is materially worse than the desktop one, and because code-server may want to set the option (or surface a preference) ahead of upstream.
At minimum, documenting
Shift+drag as the escape hatch in the terminal FAQ would already help.