Plugin actions on right-click context menus

[RaviTharuma]

Current behavior

Plugin actions can declare contexts = ["workspace" | "tab" | "pane" | ...] and can be bound to keys with type = "plugin_action". Right-click context menus (workspace, tab, pane) are still a fixed builtin list only.

Plugins such as osamahbeig/herdr-pane-mover therefore cannot appear on the pane right-click menu even when they declare a pane-oriented action. Today they ship an overlay keybind workaround instead.

Requested change

When building a right-click context menu, append enabled plugin actions whose manifest contexts include the matching target:

• workspace menu → contexts contains workspace
• tab menu → contexts contains tab
• pane menu → contexts contains pane

Selecting a plugin row should:

1. focus that target
2. invoke the action with invocation_source = "context_menu"
3. populate the normal HERDR_PLUGIN_CONTEXT_JSON fields

Empty contexts should stay keybind/CLI-only and should not add a menu row.

No new manifest field is required; reuse the existing contexts array and platform/enabled filtering already used for plugin actions.

Reason

Herdr already has the action/context model and pane/tab/workspace context menus, but no extension point connecting them. Pane-mover and similar plugins currently cannot offer the natural UX of “right-click pane → Move this pane…”.

Does this change UI, interaction, workflow, or product direction?

Yes — context menus gain plugin rows after the builtin items. Builtin items stay first; plugin rows append after them, sorted by plugin_id / action_id.

Impact details

• Mouse: right-click pane/tab/workspace shows matching plugin actions when the plugin is enabled and platform-supported.
• Plugins: authors opt in with existing contexts; no new manifest field required.
• Invocation: same command path as keybind/CLI invoke, with invocation_source = "context_menu".
• Empty contexts remains keybind/CLI-only.

Contribution intent

• I intend to open a PR for this issue.
• I understand this does not mean the issue is approved.

Implementation sketch (ready after approval)

Branch on fork: feat/plugin-context-menu-actions
https://github.com/RaviTharuma/herdr/tree/feat/plugin-context-menu-actions

Core approach:

• Snapshot menu rows as ContextMenuItem::{Builtin, Plugin} when the menu opens so render/hit-testing stay simple and the selected plugin action is stable for that open menu.
• Append enabled, platform-supported actions whose contexts match the menu kind.
• On select: focus target via existing via-api helpers, then invoke with invocation_source = "context_menu".
• Docs/changelog/tests included on the branch.

[RaviTharuma]

Opened as issue for tracking: #1776

[MustafaaYilmas]

Same need here, from a plain git angle rather than a plugin-authoring one.

I keep one space per repo, and the sidebar row already shows the branch and the ahead count. That row is exactly where I am looking when I notice I am 4 commits ahead. Right-clicking it and picking push would be the obvious next move, but the menu stops at Rename / Close / worktree, so I fall back to a terminal or a [[keys.command]] binding.

The keybind workaround works. But in a mouse-first tool it means the one surface that displays git state is the one surface that cannot act on it, and the action set the UI teaches is the only one that can never be extended.

Not asking for built-in git commands. Appending plugin actions whose contexts match the clicked target, as described above, would cover this, since a small local plugin could then own push and pull.

[Svyk]

+1 from the agents sidebar, which this thread does not cover yet.

On 0.8.2, right-click on a space still only offers Rename / Close / worktree. Right-click on an agent row does nothing at all — no menu. Plugin actions with contexts = ["pane"] (or with empty contexts) never appear, and herdr plugin log list stays empty because the click never invokes them.

That is the gap for inbox-style settle/archive: the natural click is the agent row, and there is currently no mouse surface for it. Keybinds work; the sidebar click does not.

Herdr 0.8.2, macOS, stable channel.

[ivolkoff]

+1, with a concrete use case: forking agent sessions from the pane menu.

I wrote a small local plugin with two actions, Fork right and Fork down, contexts = ["pane"]. They call a script that reads the pane's agent_session, splits, and runs claude --resume <id> --fork-session in the new pane (or codex fork <id> when the pane hosts codex). It works end to end: herdr plugin action invoke ivolkoff.fork.right exits 0, the forked pane comes up, and the invocation context carries focused_pane_id, so the script knows which pane to fork even when focus moves.

What is missing is the entry point. Forking is a spatial action — "give me this conversation again, to the right" — so the place it belongs is directly under Split right / Split down in the pane right-click menu. Today the only ways in are a keybinding and a CLI call. A keybind works for me, but it is invisible: nobody discovers it, and I have to document it for everyone I share the config with, while Split right sits one right-click away.

For what it is worth, reading 0.8.2 to check whether I had misconfigured something: ContextMenuState::items() returns Vec<&'static str> assembled from literals, and PluginActionContext appears only in field declarations and the manifest parser — nothing reads it to make a decision. So contexts = ["pane"] is inert metadata that plugin action list echoes back. Connecting those two — appending entries from enabled plugins whose action context matches the open menu kind — would cover this thread and the custom-action requests in #1672 and #3183.

Any shape of the API is fine by me. Plain append after the built-in items, no icons, no ordering control, no way to replace built-ins, would already solve it.

[ferretorres]

+1 with a concrete plugin-author case, reproduced on 0.8.2 and confirmed still absent in 0.9.0.

Problem. I maintain herdr-plugin-space-colors, which registers one action per palette: Colour: Red … with contexts = ["workspace"] and Pin: Red … with contexts = ["pane"]. They work through a keybinding or herdr plugin action invoke. Users who right-click a Space or a pane expecting to pick a colour find nothing, because the built-in menus (rename / split / zoom / close) are the whole menu. Right-click on an agent row shows no menu at all.

Root cause matches what @BjoernSchotte found in #3183: PluginActionContext is parsed from the manifest and echoed by plugin action list, but nothing reads it to make a decision. The field exists; it just has no consumer.

Smallest change that would close the gap. Give contexts its obvious consumer: an action whose contexts includes workspace appears in the workspace right-click menu, pane in the pane menu (and the agent-row menu, which is a pane), tab in the tab menu, grouped under the plugin's name. On click, invoke it exactly as a keybinding does today, with the clicked target's id in HERDR_WORKSPACE_ID / HERDR_PANE_ID and the usual HERDR_PLUGIN_CONTEXT_JSON. No new manifest syntax, no runtime registration: every plugin that already declares contexts lights up.

Happy to test a preview build against the 18 actions above and report back.

[seyeeL]

Windows data point in favor of giving contexts a consumer.

Same situation as the reports above, on 0.9.0-preview (native Windows): an action declaring contexts = ["pane", "tab", "workspace"] is reachable only through [[keys.command]] with type = "plugin_action" or herdr plugin action invoke. herdr plugin action list echoes contexts; nothing reads it to make a decision.

The recurring workaround advice ("make it a plugin, bind it to a key") does not land for mouse-first users, and on Windows it does not even work yet: the clipboard-oriented plugins I looked at (pane-id / context-locator style) shell out to pbcopy, wl-copy, xclip, or xsel, so a Windows user has to port the plugin before the workaround is available at all. I ended up writing my own local action, which is exactly the invisible per-user setup this thread is complaining about.

A menu entry that dispatches an already-declared action needs no new manifest syntax and no new plugin code, and it would make plugins that already ship today usable by mouse on every platform, including Windows.

[sonhyrd]

need this for mouse user

[traylorre]

My case: every space is a git worktree, and I keep a local web dashboard with a page per worktree. I want to open the page for a space from its sidebar row. Today that takes a click on the row and then a keybinding.

Either of these would cover it:

• What this thread asks for: list plugin actions whose contexts match in the space row's right-click menu. Agent rows would need a menu of their own, since right-click menus exist today only for spaces, tabs and panes [1].
• Control+click on a space or agent row invoking a plugin action with that row's workspace or pane context [2], using the same modifier that link handlers use for URLs inside panes [3].

[1]

herdr/src/client/shell/state.rs

Lines 531 to 549 in 7b116c0

	pub(super) enum ClientContextMenuTarget {
	Workspace {
	workspace_id: String,
	is_git: bool,
	is_linked_worktree: bool,
	has_worktree_children: bool,
	collapsed: bool,
	},
	Tab {
	tab_id: String,
	workspace_id: String,
	},
	Pane {
	pane_id: String,
	workspace_id: String,
	source_pane_id: Option<String>,
	has_manual_label: bool,
	right_click_passthrough: bool,
	},

[2]

herdr/src/api/schema/plugins.rs

Lines 355 to 361 in 7b116c0

	pub enum PluginActionContext {
	Global,
	Workspace,
	Tab,
	Pane,
	Selection,
	}

[3] https://herdr.dev/docs/plugins/#link-handlers