Feature request: dispatch a session with --plugin-dir from claude agents (develop an installed plugin in-place)

Feature request

In the new claude agents view (research preview, docs: https://docs.claude.com/en/docs/claude-code/agent-view), give the dispatch input a first-class way to start a session in a repo with --plugin-dir <that-repo> set for just that session — so you can develop an installed plugin in-place without dropping to a shell.

Setup

• claude agents opened from a parent directory containing many sibling repos (e.g. ~/HUB).
• Several of those repos are also plugins I have installed at user scope. Concrete example: nf-visualize lives at ~/HUB/nf-visualize and is also installed as a user-scope plugin.
• Per the "Test your plugins locally" section of the Create plugins doc: when --plugin-dir is passed to claude, a same-name local plugin takes precedence over the installed marketplace plugin for that session. This is exactly the right primitive for plugin development — I just want the local source to win while I iterate on it.

The gap

There is no ergonomic way from inside claude agents to dispatch a session into a repo with --plugin-dir <that-repo> set:

• @<repo> <prompt> (the documented @<repo> mention form) dispatches a session into the repo's directory — but does not pass --plugin-dir, so the user-scope installed copy still wins. The local source I'm trying to develop is shadowed.
• claude agents --plugin-dir <path> works, but applies to the whole agent view session. Every dispatch from that view inherits the flag. Wrong granularity when I'm also using the same agent view to dispatch unrelated work in other repos.
• The dispatch input does not (today) accept ad-hoc CLI-style flags like --plugin-dir @<repo> <prompt>.

Current workaround

1. Attach to some existing background session (or open a fresh one).
2. Drop to ! bash.
3. Run claude --bg --plugin-dir . "<prompt>" from inside the plugin repo.
4. Detach, return to agent view, find the new row.

Three context switches and a shell detour for what should be one mention. It also means the plugin-dir intent is hidden in a transient bash command instead of being expressed at the dispatch site.

Ask

A first-class, per-dispatch way to set --plugin-dir (pointing at the targeted repo) from the claude agents dispatch input. Open to whatever shape fits the existing UX best — non-exhaustive ideas:

• A modifier on the @<repo> mention syntax (e.g. @@<repo>, or a suffix like @<repo>!plugin) that means "dispatch into the repo AND set --plugin-dir to its path".
• A per-suggestion key while an @<repo> row is highlighted (e.g. p or Ctrl+P) that toggles "dispatch as plugin-dir target" before pressing Enter.
• Auto-detect: if the targeted repo has a plugin.json (or whatever the canonical plugin manifest marker is) at its root, auto-add --plugin-dir <that-repo> for that session, with a setting to disable.
• A CLI-flag-style prefix accepted by the dispatch input: e.g. --plugin-dir @<repo> <prompt> — discoverable from existing CLI muscle memory.

Any one of these would remove the bash detour and make plugin development workable from the agent view, which (per the doc) is already positioned to be the primary entry point.

Why this matters

Plugin authors are exactly the audience most likely to live in claude agents (lots of parallel sessions, lots of iteration). Right now the view is hostile to the workflow it should be most natural for: editing a plugin's source and immediately running a session against the local copy. Closing this gap turns plugin development from "remember to drop to bash" into "mention the repo".

Thanks!