Decouple mouse capture from the fullscreen renderer (macOS Terminal.app: no ⌘-click on URLs, forced copy-on-select, no bypass modifier)

Status Open
Reported on v2.1.251
Maintainer reply None cached
Activity 0 comments · opened Aug 30, 2026

What I'm trying to do

Open a URL that Claude Code printed, and select text with the mouse, while using
the fullscreen renderer on macOS Terminal.app.

What happens

With "tui": "fullscreen", Claude Code takes ownership of the mouse, so
Terminal.app never sees the events:

  • ⌘-click / ⌘-double-click on a printed URL does nothing — Terminal's own URL

detection never fires.

  • Dragging selects inside Claude Code's UI and auto-copies to the clipboard,

which is not Terminal.app behaviour and cannot be turned off. (defaults read
com.apple.Terminal
has no copy-on-select key at all — only SelectionColor
so this is Claude Code's own selection handling.)

Why "just emit OSC 8 hyperlinks" is not the fix

Terminal.app has never implemented OSC 8. Emitting hyperlink escapes there
produces visible garbage rather than a link:

$ printf 'OSC8 test: \033]8;;https://example.com\033\\clickable-label\033]8;;\033\\\n'
OSC8 test: ]8;;https://example.com\clickable-label]8;;\

The only thing that works in Terminal.app is a plain URL handed to the
terminal's own detector
— which requires Claude Code not to be holding the
mouse. So this is a mouse-ownership issue, not a hyperlink-rendering one.

Why there is no user-side workaround

Terminals that capture the mouse usually offer a bypass modifier — iTerm2 uses
Option, so you can always select natively. Terminal.app has no equivalent.
Once an app enables mouse reporting there, the user has no way to reach the
terminal's own selection or URL handling.

The only current lever couples two unrelated things

tui controls both the renderer and mouse ownership. Setting
"tui": "default" does restore ⌘-click and native selection — but it also drops
the alt-screen renderer and virtualized scrollback, and the main-screen redraw on
long output was laggy enough that I reverted within minutes.

So today the choice is: fluid rendering with an unusable mouse, or a usable mouse
with a renderer that lags. Those two concerns have no reason to be tied together.

Proposed

A setting to disable mouse capture independently of the renderer, e.g.

{
  "tui": "fullscreen",
  "tui.mouse": false        // or { "tui": { "mode": "fullscreen", "mouse": false } }
}

so terminals without a bypass modifier can keep native selection and URL
handling while still getting the fast renderer. Scroll-wheel handling could fall
back to the terminal's own scrollback, which is what those users expect anyway.

Environment

  • Claude Code 2.1.251
  • macOS, TERM_PROGRAM=Apple_Terminal 455.1, TERM=xterm-256color
  • ~/.claude/settings.json: "tui": "fullscreen"

View original on GitHub ↗