Feature: `osc open <url>` — open URLs in local browser over SSH

[schickling-assistant]

Use case

When SSH'd into a remote machine, CLI tools frequently need to open URLs in the user's local browser (e.g. OAuth flows, gh browse, MCP authentication). open / xdg-open doesn't work because there's no local display server on the remote host.

The terminal is the only communication channel back to the local machine — the same channel osc already uses for clipboard via OSC 52.

Proposal

Add an osc open <url> command that emits an escape sequence instructing the terminal emulator to open the given URL in the user's default browser. This mirrors the existing osc copy / osc paste pattern:

osc copy   → OSC 52 → terminal writes to clipboard
osc open   → OSC ?? → terminal opens URL in browser

The command would need to handle tmux/screen passthrough wrapping the same way osc copy already does.

The missing piece: a standard OSC sequence

There is currently no widely-adopted OSC sequence for "open this URL." The closest prior art:

• OSC 8 — creates clickable hyperlinks in terminal output, but requires user interaction (click) and can't programmatically trigger opening
• iTerm2 OSC 1337 — proprietary extension for various features, no URL-open variant
• Kitty remote control — kitty-specific protocol, not portable (docs)
• Custom OSC 451 (toxicfrog/osc-wrapper) — ad-hoc convention used with a custom SSH wrapper

This feature would require proposing a new OSC sequence number and getting terminal emulators to adopt it. OSC 52 spread the same way — a tool started emitting it, terminals adopted it over time.

A reasonable convention might be something like:

OSC 13 ; <url> ST

(OSC 13 appears unused in major terminals. Open to alternatives.)

Terminal adoption needed

For this to work end-to-end, terminal emulators would need to implement the receiving side. Having a concrete CLI tool + proposed sequence gives terminal authors something tangible to adopt — similar to how osc helped drive OSC 52 clipboard adoption.

Relevant terminal discussions / feature requests:

• Ghostty: No scripting API yet (discussion #2353), no programmatic URL opening (discussion #5627), SSH integration (discussion #3087)
• WezTerm: Has user-var-changed events via OSC 1337 that could react to URL open requests (docs), open-uri event hook (docs)
• Kitty: Has remote control protocol that can launch commands on the local machine over SSH (docs)
• Windows Terminal: Open feature request for xdg-open over SSH (issue #14331)
• OSC 8 hyperlink adoption tracker: Alhadis/OSC8-Adoption

Alternatives considered

• Socket forwarding (superbrothers/opener): works today but requires a local daemon + SSH RemoteForward config per host. Heavier setup, doesn't leverage the existing terminal channel.
• SSH reverse tunnel + HTTP (blog.rymcg.tech): similar trade-offs, more moving parts (socat, systemd units).

The OSC approach would be zero-config for users who already have osc installed — just osc open <url> and it works (once their terminal supports it).

Related resources

• Hyperlinks in Terminal Emulators — comprehensive overview of OSC 8 and terminal hyperlink support
• Standards for ANSI escape codes — overview of the OSC landscape
• State of the Terminal — survey of modern terminal capabilities