[idea] Add "Copy pane id" to the pane right-click context menu

[wine-fall]

Motivation

My main use case for Herdr is orchestrating coding agents across panes. When an agent session in one pane needs to interact with another pane (read it, prompt it, split next to it), I have to tell my agent which pane I mean — and natural language ("the pane on the top right running claude") is imprecise. The public pane id (w1:p2) is the exact handle the CLI accepts, but there is currently no way to see or copy it from the TUI itself:

• inside a pane you can echo $HERDR_PANE_ID
• from a shell you can run herdr pane list

Both require typing into a free shell, which is awkward precisely when the target pane is busy running an agent — the situation where you most need its id.

Proposal

Add a "Copy pane id" item to the existing pane right-click context menu. Selecting it copies the pane's public id (e.g. w1:p2) to the clipboard and shows a toast confirming the copy.

Implementation sketch, kept intentionally within existing patterns:

• append the item to the ContextMenuKind::Pane item arrays in src/app/state.rs
• handle it at the two label-matched dispatch sites in src/app/input/modal.rs, resolving the id via the existing public_pane_number / public_pane_id_for_number path
• copy via the existing selection::write_osc52_bytes, so both local clipboard and SSH (OSC 52) sessions work
• confirm via the existing ToastNotification mechanism

This is a pure TUI/client change: no server state, API, events, or protocol changes.

I have drafted the implementation with tests and would be happy to open a PR if this idea is accepted.

[wine-fall]

Quick update: I went ahead and built this to make it concrete.

Right-click a pane → Copy pane id → the public id (w1:p2) lands on the
clipboard (via the existing write_osc52_bytes path, so it also works over
SSH), with a toast confirming what was copied:

The branch is here: https://github.com/wine-fall/herdr/tree/feat/copy-pane-id
— it follows the existing context-menu/label-dispatch/toast patterns, is a
pure TUI/client change (no server state, API, or protocol changes), and comes
with unit tests covering both dispatch paths. just check passes locally.

My day-to-day motivation: when orchestrating coding agents across panes, I
constantly need to tell the agent in one pane exactly which other pane to
target, and the pane id is the only unambiguous handle the CLI accepts. This
makes grabbing it a one-click action.

Happy to open a PR if this gets accepted.

[xRyul]

Yes please, either contextmenu or around the pane itself (toggled through the settings).

So then it becomes a matter of just saying "read pane XYZ" - and it will read it immediately without needing to waste context and tokens on finding where it is - in which workspace - in which tab - in which pane - it will just go directly into it.

[wine-fall]

Thanks! that's exactly the workflow I had in mind. Showing the id on the pane itself (behind a setting) sounds like a nice follow-up; I'd keep this first change scoped to the context-menu item since it's small and follows existing patterns, but I'd be happy to explore the always-visible variant in a separate proposal if there's interest.

Would love to hear the maintainers' take on this. The branch is ready and tested, and I'm happy to open a PR or adjust the approach.

[wine-fall]

@ogulcancelik sorry for the ping, and no rush if this isn't a priority right now.

There seems to be some interest in this one (a few upvotes, and @xRyul described the same pain point: being able to say "read pane XYZ" instead of burning context figuring out which workspace/tab/pane the agent should target).

The change itself is small and already done: a "Copy pane id" entry in the pane context menu that copies the public id (w1:p2) through the existing write_osc52_bytes path, with a toast confirming the copy. It follows the existing context menu, label dispatch, and toast patterns, stays a pure TUI/client change (no server state, API, or protocol changes), and has unit tests covering both dispatch paths. just check passes locally. Branch: https://github.com/wine-fall/herdr/tree/feat/copy-pane-id

Per CONTRIBUTING.md I'm holding off on a PR until there's an issue and approval, and I'm not in .github/APPROVED_CONTRIBUTORS yet. If this is something you'd take, I'm happy to open a PR once that's sorted, adjust the approach, or drop it if it doesn't fit your plans for the pane surface.

On @xRyul's suggestion of showing the id on the pane itself behind a setting: that sounds like a nice follow-up, but I'd keep this first change scoped to the context menu item.

[ogulcancelik]

i'm refactoring representation-ui layer atm, and not sure if adding this to the menu is a cool idea. but this could be a plugin i think? a keybind that when you press copies the focused pane's id to your clipboard?

[wine-fall]

@xRyul I built this as a plugin, since the maintainer is mid-refactor on the representation-UI layer: https://github.com/wine-fall/herdr-copy-pane-id

herdr plugin install wine-fall/herdr-copy-pane-id

Herdr doesn't surface plugin actions in the UI, so you bind them yourself in ~/.config/herdr/config.toml:

[[keys.command]]
key = "prefix+y"
type = "plugin_action"
command = "wine-fall.copy-pane-id.copy-focused"

[[keys.command]]
key = "prefix+i"
type = "plugin_action"
command = "wine-fall.copy-pane-id.toggle-id-labels"

Then herdr server reload-config.

prefix+y copies the focused pane's id. prefix+i is your suggestion: plugins can't draw native UI, so it relabels every pane, which puts the id on the border (id · name if the pane already has a name, restored when toggled off).

One caveat: it copies to the clipboard of the machine Herdr runs on, so over SSH the id lands on the remote box rather than your local terminal.

[seyeeL]

Extending this from "pane id" to the pane's full session identity — same mouse-first problem, slightly bigger payload.

My case: I often want to hand one pane to another agent ("go read / continue the work in pane X"), or paste a pane's identity into a chat. What is actually useful is a small block: public pane id, agent kind + status, tab and workspace ids, terminal id, and cwd. Today the only ways to get that are echo $HERDR_PANE_ID in a free shell or herdr pane list from a shell — awkward exactly when the pane I care about is busy running an agent.

I tried the plugin route first: a local action that reads HERDR_PLUGIN_CONTEXT_JSON + herdr pane list, writes the block to the clipboard and confirms with a toast. It works end to end, but it needs a [[keys.command]] binding, which is the discovery problem this thread is about. The existing clipboard-copy plugins are also Unix-only (pbcopy / wl-copy / xclip / xsel), so on native Windows (0.9.0-preview) there is no plugin-based path either without porting them.

So: +1 for the built-in menu item, and if it lands, copying an identity block instead of only w1:p2 would cover the agent-handoff use case that motivated this thread. Your point about going through the OSC 52 path matters for SSH sessions, where the plugin route copies to the wrong machine's clipboard.