macOS: Cmd+click can't open OSC 8 file:// links while an app has mouse reporting on (e.g. Claude Code fullscreen)

[Astro-Han]

On macOS, Cmd+click does not open OSC 8 hyperlinks while a fullscreen TUI has mouse reporting enabled (for example Claude Code's fullscreen renderer, v2.1.89+). The same links open fine in a normal shell, and on Linux they open with Ctrl+click. It looks like the Cmd modifier is dropped when the click is forwarded to the application.

1. The app emits a proper file:// OSC 8 link.

Captured Claude Code's output with asciinema rec -f raw -c claude cc.raw, then extracted the OSC 8 sequences:

params='id=…'  uri='file:///tmp/hello.txt'

So the link is well-formed: a file:// scheme plus an id=. The bare path you see on hover is Ghostty's own URL regex matching the displayed text /tmp/hello.txt, separate from the OSC 8 link underneath. (Same symptom as the older #11907 / #11908, but those were on a pre-fullscreen Claude Code; the cause below is specific to mouse reporting.)

2. In a plain shell, Cmd+click opens these links fine.

With no app mouse reporting active, all of these open on Cmd+click in 1.3.1 (point file:// at any path that exists):

printf '\e]8;;file:///tmp/x.txt\e\\/tmp/x.txt\e]8;;\e\\\n'      # file:// OSC8
printf '\e]8;;https://example.com\e\\example.com\e]8;;\e\\\n'   # https OSC8

So OSC 8 handling itself is fine.

3. It breaks only while an application has mouse reporting enabled.

Claude Code's fullscreen/alt-screen TUI turns mouse reporting on. In that mode, Cmd+click reaches the app with the Cmd modifier stripped, byte-identical to a plain click, so neither the app nor Ghostty opens the link.

Minimal probe (run in Ghostty; then plain-click, Cmd+click, Cmd+Shift+click, then q):

import sys,termios,tty,re,os
fd=sys.stdin.fileno(); old=termios.tcgetattr(fd)
o=lambda s:(sys.stdout.write(s),sys.stdout.flush())
pat=re.compile(rb"\x1b\[<(\d+);(\d+);(\d+)([Mm])")
try:
    tty.setraw(fd); o("\x1b[?1000h\x1b[?1006h"); o("click; q to quit\r\n"); buf=b""
    while True:
        d=os.read(fd,1024)
        if not d or d==b'q': break
        buf+=d; last=0
        for m in pat.finditer(buf):
            cb=int(m.group(1)); mods=[n for b,n in ((4,'Shift'),(8,'Alt'),(16,'Ctrl')) if cb&b]
            o(f"Cb={cb} {'press' if m.group(4)==b'M' else 'release'} mods={mods or ['none']}\r\n"); last=m.end()
        buf=buf[last:]
finally:
    o("\x1b[?1000l\x1b[?1006l"); termios.tcsetattr(fd,termios.TCSADRAIN,old)

Result here:

gesture	forwarded to the app
plain click	Cb=0 mods=[none]
Cmd+click	Cb=0 mods=[none] (identical to plain, no Cmd bit)
Cmd+Shift+click	(nothing: shift-capture bypass; Ghostty opens it itself)

Cmd+Shift+click opens the link because Shift hands the click back to Ghostty (shift-capture). On Linux, plain Ctrl+click works because Ctrl is encodable in the SGR mouse report; macOS Cmd (Super) is not, which is why this is macOS-specific (see #12494).

Question: since macOS Cmd (Super) can't be encoded in the SGR mouse protocol, forwarding a Cmd+click drops the modifier and the app can't distinguish it from a normal click. Should Ghostty keep Cmd+click as a terminal-level open-link gesture while mouse reporting is active, the way the Shift bypass already does? The same Cmd+click works in cmux and is reported to work in iTerm2.

Environment: Ghostty 1.3.1 (stable, Metal, coretext), macOS 26.5 (25F71), Claude Code 2.1.185, default Ghostty config. Happy to share a sanitized asciinema cast.

[pluiedev]

If you're a human, rewrite this in your own words and make a new discussion. We do not entertain fully LLM-generated reports.

[sirianni]

Thank you for this bug report! The workaround of using Cmd + Shift + Click works for me. It would be great if this could be addressed in Ghostty itself.

[Astro-Han]

Thanks! I was using the cmd + shift + click workaround as well. I'm hoping there could be a fix adressing this issue.

[Astro-Han]

I opened another discussion thread to continue the issue report. We could discuss over there. #13073