Add support for OSC 1337 OpenURL?

[debdutgoswami]

What

Would the team be open to supporting iTerm2's OSC 1337 ; OpenURL=<base64> escape sequence in Ghostty, behind a default-off config option?

Why

The use case that prompted this: when SSH'd into a remote machine, I want a command like zed . (or code .) to open the editor on my local machine, pointed at the remote path over SSH. iTerm2 supports this via OSC 1337 OpenURL - the remote shell prints an escape, iTerm2 decodes it locally, and macOS routes the URL (e.g. zed://ssh/user@host/path) to the right app handler.

Today in Ghostty:

• The closest thing is OSC 8 hyperlinks, but those require a user click. OSC 1337 OpenURL is unsolicited - it's the right primitive for "host-side action triggered by remote program".

How (sketch)

• Parse ESC ] 1337 ; OpenURL=<base64> BEL, decode, validate (reject control chars, cap length).
• Dispatch through the existing open_url apprt action - already used by OSC 8 click handling, already implemented on macOS (NSWorkspace) and GTK (xdg-open / OpenURI portal).
• Gate behind a new config option, default off, because OSC 1337 OpenURL lets a remote SSH server pop arbitrary URL handlers on the host machine (mailto:, zoom:, file://, custom schemes…). Similar reasoning to why clipboard-write is gated.

Status

I have a working patch on a fork I'm using daily, with parser tests and the default-off config gate. ~190 lines, follows existing patterns (report_pwd, show_desktop_notification).

Curious to hear what the team thinks, especially on:

1. Is this in scope for Ghostty, or considered too iTerm2-specific?
2. Naming / default for the config option?
3. Any extra validation you'd want beyond control-char + length?

Seems related but with a different use-case but it is the same thing I believe: #11105

PS: I do not know zig at all. I understand the fundamentals of OSC but the actual implementation of it in zig, is vibe coded via LLM.