[idea] similar to clipboard write, can we have 'open url'

[dvic]

idea / problem

I realized that some of my plugins/shortcuts that open browser urls (like opening PR) don't work when using herdr --remote ..., because xdg/opening is not locally on the client.

requested change

Add a feature similar to clipboard write event for opening urls.

why you want this

it makes the experience between local and remote herdr more uniform :)

[dvic]

I have a working patch for this up at master...dvic:herdr:dvic/patch-open-url, seems to be working quite well! @ogulcancelik if there is interest for such a feature i can look in more detail at it and polish it more, but I can imagine that you want to work yourself on such a large change to the codebase, let me know!

[ShengJ96]

Hitting this too, from a slightly different angle than the original post: my herdr server runs on a headless Linux box that I attach to with herdr --remote from Ghostty on my laptop. Every link in a pane is effectively dead — Ctrl+click tries to open it on the server, which has no display at all, so nothing ever reaches the machine I am actually looking at.

For agent work this comes up constantly: PR links, CI runs, localhost dev servers, docs. Right now the only workaround is copying every URL out by hand.

The remote case feels like more than a preference to me: --remote already means "I am here, the machine is over there", so the server is the one place the browser definitely should not open.

(Related: I filed #2903 for the silent-failure and zombie side of this, which was accepted as a bug — so this code path is being touched right now.)

[yazanabuashour]

I run into this every day too. I use herdr --remote from Ghostty on my MacBook to a Linux server, and when an agent posts a PR link or a localhost URL, clicking it doesn't open it on my laptop.

I use cmd+shift-click, because the terminal handles the click instead of passing it to herdr. It's another keybind to remember, though.

Copying text already works great.

[plainlystated]

Another data point, from the opposite setup as the headless case above: my --remote server is a Linux box that has its own active desktop session (I attach from another machine with herdr --remote <host> --session <name>).

In that setup the failure mode is silent success on the wrong machine. Agents in panes (Claude Code here) open URLs programmatically via $BROWSER / xdg-open — no click involved — and both exit 0, because the server has a perfectly good graphical session to hand the URL to. The tabs open in the server's browser: nothing errors, no fallback URL gets printed, and from the client it looks like the open worked.

Verified on the server side — both test opens landed in the server's running chromium:

systemd[1058]: Started [systemd-run] /usr/bin/uwsm-app -- /usr/bin/chromium https://example.com.

So a bridge would ideally cover programmatic opens from inside managed panes too, not just routing pane clicks — e.g. herdr injecting a BROWSER shim into panes that forwards to the client's open-url event, the same way clipboard writes are bridged. The headless case at least fails visibly-ish; the desktop-server case succeeds somewhere you aren't looking.

[kasperbn]

Another concrete use case for this is an explicit plugin action that opens a web UI.

TreeTop provides a Herdr plugin menu with task-specific actions. Some actions start terminal tools, while others should open URLs such as OpenCode Web, VS Code Web, or a task preview. With the Herdr client on my laptop attached to a remote Linux server, the plugin command runs remotely, so the OS browser opener targets the wrong machine (or a headless machine) instead of the laptop where I selected the action.

The desired behavior is for a user-invoked plugin action to ask the currently attached Herdr client to open a validated HTTP(S) URL using the same local browser behavior Herdr already uses for Ctrl/Cmd-clicked links. A clear failure when no capable client is attached would be fine.

This is narrower than the general client-local actions proposal in #3564: no arbitrary local command execution, just opening a safe web URL on the viewing client.