copy-context writes the server's clipboard, unreachable from a remote client

[mingrath]

With herdr 0.9 multi-machine (herdr machine add), plugin actions run on the selected server. src/clipboard.ts writeClipboard() uses spawnSync("pbcopy"), so copy-context lands on the server's clipboard. A client on a different machine never receives it — herdr exposes no client-clipboard API to plugins, and there is no OSC 52 fallback.

Repro

1. Run the herdr client on Mac A.
2. herdr machine add <macB> --label "Mac B".
3. Select Mac B's workspace in the sidebar.
4. Invoke copy-context.

Text is on Mac B's clipboard; Mac A's is unchanged. Same for any action that writes the clipboard.

Suggested fix
Emit OSC 52 alongside the native writer so the client terminal picks it up when the plugin runs on a remote server.

Versions
herdr 0.9.0 (both ends), plugin 5d94eadfed96e4064b692718cef143afeb0931d3, macOS arm64, Ghostty 1.3.1.

Note: #23 is adjacent but distinct — that is about capture failing on a headless server, this is about which machine the copy lands on.

[backnotprop]

Thanks, this is accurate and the repro is clear. Confirmed in Herdr's source: 0.9.0 forwards OSC 52 from pane output to the viewing client, but plugin actions run with piped stdout and no terminal, so an action can't reach the client's clipboard that way, and Herdr has no plugin clipboard API.

Plan: every copy that runs inside a pane (the manager's y, c and Shift+C, and the TUI's copy) will emit OSC 52 alongside the native writer, which fixes those on remote workspaces. The global actions copy-context and copy-archive can't be fixed inside the plugin without a visible popup; we'll raise a clipboard API with Herdr and link it here. If you'd rather see the popup approach in the meantime, say so.

[mingrath]

Thanks — the diagnosis matches what I see in the source, and the pane-based plan makes sense. One note on the global actions, offered as an opt-in escape hatch rather than a proposed default.

The global actions copy-context and copy-archive can't be fixed inside the plugin without a visible popup

That's right for OSC 52 specifically — no TTY, no escape sequence. But the terminal isn't the only channel back to the client. When the client and server are already on a mesh VPN (Tailscale, ZeroTier, plain WireGuard), the plugin has a routable path to the viewing machine and doesn't need a TTY at all.

Concretely, a sink on the client:

// clip-sink.ts — bind to the VPN address only, never 0.0.0.0
import { spawnSync } from "node:child_process";

Bun.serve({
  hostname: process.argv[2],
  port: 9999,
  fetch: async (req) => {
    spawnSync("pbcopy", { input: await req.text() });
    return new Response("ok\n");
  },
});

and an env-gated branch at the top of writeClipboard (src/clipboard.ts:63), before the existing writeCommands() loop:

const sink = process.env.HERDR_ANNOTATE_CLIPBOARD_URL;
if (sink) {
  const relayed = spawnSync("curl", ["-sS", "--max-time", "3", "--data-binary", "@-", sink], {
    input: text,
    stdio: ["pipe", "ignore", "ignore"],
  });
  if (relayed.status === 0) return { ok: true, value: undefined };
}

curl rather than fetch keeps writeClipboard synchronous, matching the native writers it sits next to. Unset env var means one lookup and the current behaviour, so it's inert for everyone not opting in.

Because it lands in writeClipboard, it covers every caller in one place — export.ts:19 (copy-context), archive-workflow.ts:38 (copy-archive), manager.ts:217 and manager-copy.ts:21 — including the two the OSC 52 work can't reach.

Verified on herdr 0.9.0 / plugin 5d94ead / macOS arm64: ran the real copy-context action against a patched copy with the sink on the client, and the Markdown arrived on the client's clipboard.

Two things worth flagging honestly:

• I first tried the obvious while true; do nc -l $IP 9999 | pbcopy; done. It silently drops copies — measured a ~1s rebind gap between loop iterations where a send is refused. A persistent listener is required; the netcat one-liner is a trap.
• Whoever runs the sink is trusting their VPN's membership as the auth boundary, and the sink must bind to the VPN address rather than all interfaces. On Tailscale you can narrow it further with a grant scoped to tcp:9999.

I'm not proposing this as the default. It only helps people already on a mesh VPN, it needs a background process on the client and an address to configure, and that's more setup than a plugin should ask of everyone. The native Herdr clipboard API is still the right fix, and I'd rather have that than this — please do link the upstream issue here when you file it, happy to add the remote-workspace repro to it.

The ask is just that the env-gated branch is a small, inert-by-default patch that unblocks copy-context and copy-archive for VPN users in the meantime. Happy to open a PR with it plus a README note if you want it; equally happy to keep it in my own fork if you'd rather not carry the surface area until the API lands.

Re: the popup approach — I'd skip it for my use case. A popup per copy is worse than the current failure for me, since I'd rather it quietly land on the wrong machine than interrupt the flow.

[backnotprop]

The pane half is merged on main (#42): copies from the annotation manager (y, c, Shift+C) in both runtimes now emit OSC 52 alongside the native write, so on Herdr 0.9.0 they reach the clipboard of the machine you're sitting at, and they still work on a server with no clipboard tool. The TUI already copied that way; #68 pins it with tests. Reinstall the plugin to pick it up.

copy-context and copy-archive remain server-side until Herdr offers plugins a clipboard path; we'll link that request here. We'll come back to you on the relay proposal separately.

[backnotprop]

Filed the upstream ask for the two keybound actions: herdrdev/herdr#3907