Cmd+click no longer opens links while an app has mouse reporting on (macOS)

[Astro-Han]

Issue Description

On macOS, once an application turns on mouse reporting, Cmd+click stops opening links (OSC 8 / file://). The same links open fine with Cmd+click in a normal shell tab, so it only breaks while some app has mouse reporting active.

I first hit this with Claude Code's fullscreen TUI, but it reproduces without it using the small script below, so this looks like a terminal-side thing rather than an app bug.

I poked at it with a probe that prints the mouse events the app receives (SGR mouse, 1000 + 1006). A plain click arrives as Cb=0 with no modifiers, and a Cmd+click arrives the exact same way: Cb=0, no modifiers. Same bytes, the Cmd is just gone. So once the click is forwarded, nothing downstream can tell a Cmd+click from a normal click.

My guess is the xterm mouse protocol only has modifier bits for Shift/Meta/Ctrl and nothing for the macOS Command key, so there's nowhere to put Command when the event is forwarded. Ctrl+click still works (Ctrl has a real bit), and Shift+Cmd+click works too, because Shift makes Ghostty take the click instead of passing it on.

So my question is really: Ghostty still sees the real Command key before it forwards anything. Could it open the link itself on Cmd+click while mouse reporting is on, the way it already does for the Shift bypass, instead of sending a bare click to the app? Right now Shift is the only thing that makes Ghostty keep the click.

Same symptom as the older #11907 / #11908, but those were on a pre-fullscreen setup. This is specifically about the mouse-reporting path, with an isolated repro.

P.S. I opened #13060 on this earlier and was asked to rewrite it in my own words, so this is that rewrite.

Expected Behavior

Cmd+click on a link opens it in the default app/browser, the same as in a normal shell tab, even while an application has mouse reporting enabled. If that's not possible by design, it'd help to document the gesture that is expected here.

Actual Behavior

While mouse reporting is on, Cmd+click does nothing. The click is forwarded to the application as a plain click with the Command modifier stripped. Only Ctrl+click or Shift+Cmd+click open the link.

Reproduction Steps

No Claude Code needed. Save this as repro.sh and run it in Ghostty:

#!/usr/bin/env bash
: > /tmp/ghostty-link-test.txt
printf '\e[?1000h\e[?1006h'                       # turn on SGR mouse reporting
printf '\e]8;;%s\e\\%s\e]8;;\e\\\n' \
  'file:///tmp/ghostty-link-test.txt' '/tmp/ghostty-link-test.txt'
printf 'Cmd+click the path above (it should open). Press Enter to quit.\n'
read -r _
printf '\e[?1000l\e[?1006l'                       # turn it back off

1. Run bash repro.sh in Ghostty.
2. Cmd+click the printed path -> nothing happens.
3. Shift+Cmd+click or Ctrl+click the same path -> it opens.
4. Press Enter to exit.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 26.5 (build 25F71)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

Reproduces with default configuration.
(mouse-reporting and link-url are on by default).

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[rhodes-b]

This isnt a bug when in the alternate screen or mouse reporting you need to hold shift to override the mouse capture behavior.

[Astro-Han]

Thanks, I'm currently using Shift+click to override the mouse capture behavior, so I probably mislabeled this as a bug. It's more of a feature question: on macOS Cmd+click is the normal way to open a link, and Ghostty still has the Command key before it forwards the click, so I was wondering if Cmd could also trigger the bypass the way Shift does, which keeps the gesture the same whether or not an app has mouse reporting on. Totally understand if that's by design; just wanted to ask.

[rhodes-b]

There is currently no way besides shift to override it, that isn't going to change it was done that way so applications running can capture cmd/ctrl + click if they desire

This would let you configure the mouse actions ie remove the shift override
#3848