Fullscreen renderer opens links on unmodified mouse click in terminals without a native OSC 8 link handler (contradicts documented v2.1.181 behavior)
Summary
In fullscreen TUI mode ("tui": "fullscreen" / CLAUDE_CODE_NO_FLICKER=1), Claude Code opens hyperlinks on a plain, unmodified mouse click when running in a terminal that has no native OSC 8 link handling layer. This contradicts the documented behavior since v2.1.181 ("a plain click without holding Cmd or Ctrl no longer opens links, matching native terminal behavior" — https://code.claude.com/docs/en/fullscreen), and makes accidental link-opening very easy while scrolling/clicking around the transcript.
Environment
- Claude Code: 2.1.227
- OS: macOS (Darwin 25.5.0)
- Terminal: termio (an xterm.js-based terminal emulator, not one of the terminals with a built-in link handler like Warp/Ghostty/VS Code)
- Renderer: fullscreen (
"tui": "fullscreen")
What happens
- Hovering a link shows no underline / no pointer change → the terminal is not handling the link itself (no OSC 8 hover layer active during mouse tracking), so clicks are forwarded to Claude Code.
- A plain left click on a link immediately opens it in the browser.
- For comparison, in a plain shell in the same terminal, OSC 8 links printed via
printf '\e]8;;https://example.com\e\\test\e]8;;\e\\\n'correctly require Cmd+Click and show hover underline — so the single-click behavior inside Claude Code comes from Claude Code's own mouse handling, not the terminal.
Evidence: the click events Claude Code receives are unmodified (button code 0)
Captured with SGR mouse reporting enabled in the same terminal (printf '\e[?1000h\e[?1006h'; cat -v):
^[[<0;35;19M^[[<0;35;19m # plain left click: press/release, button code 0
0;17;18M0;17;18m # Cmd+left click: identical bytes, button code 0- Plain click is encoded correctly (
0= no modifier bits). - Cmd+click produces byte-identical events (the xterm mouse protocol has no Cmd modifier bit; this terminal does not remap Cmd to Meta).
So from the event stream, Claude Code cannot distinguish plain click from Cmd+click here — and it currently chooses to open the link on the unmodified click (button code 0, no Shift/Meta/Ctrl bits). Per the documented v2.1.181 behavior, a click without modifier bits should not open a link.
Expected behavior
- A mouse click event with no modifier bits set should never open a link, in any terminal.
- If the terminal cannot report a modifier that the platform gesture requires (Cmd on macOS is not representable in the xterm mouse protocol), the safe default should be "do not open", possibly with Ctrl+Click (modifier bit +16, which is representable) as the fallback gesture.
Workarounds tried
| Workaround | Result |
|---|---|
| CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 | Stops accidental opens, but Cmd+Click can no longer open links either (all clicks ignored; terminal has no link layer to take over) |
| CLAUDE_CODE_DISABLE_MOUSE=1 | Links behave natively again (terminal-side Cmd+Click works), but mouse wheel scrolling in the fullscreen TUI is lost |
| "tui": "default" | Works, but gives up fullscreen rendering |
None of these preserves the full combination of: wheel scrolling + no accidental single-click opens + a working open-link gesture.
Suggested fix
In the fullscreen renderer's link-click handling, require a nonzero modifier bit (Shift/Meta/Ctrl) in the SGR mouse event before opening a URL. Terminals with their own link handler (Warp/Ghostty/VS Code, already special-cased) are unaffected; terminals without one get safe, non-accidental behavior consistent with the docs.