Repository navigation
[FEATURE]: allow plugins to switch active primary agent (custom primary agent handoff) #14528
Closed as not planned
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
What I’m trying to do
HI. I’m defining my own primary agent (e.g. ideation) and I want to ship a plugin that provides an ideation_exit tool.
When the tool hands off to another primary agent (usually build), I want the TUI to update its active agent selector too.
Server-side handoff is already possible by injecting a synthetic user message with agent: "build", but the TUI selector doesn’t follow.
So the UI can show the wrong active agent and the next user input may be sent with the wrong agent.
Current behavior
TUI currently auto-switches local.agent only for plan_enter / plan_exit (hardcoded).
Plugin-defined handoff tools (like ideation_exit) can’t trigger the same UI update.
Proposal
Add a first-class TUI event/intent to set the active primary agent:
- Event:
tui.agent.set - Payload:
{ name: string } - Expose it through the same plumbing as other TUI events (so plugins can emit it)
- TUI handles it by calling
local.agent.set(name)
This would let plugins keep the agent selector in sync after a custom primary-agent handoff.
References
- Hardcoded mapping today:
packages/opencode/src/cli/cmd/tui/routes/session/index.tsx - Existing TUI event plumbing:
packages/opencode/src/cli/cmd/tui/event.ts,packages/opencode/src/server/routes/tui.ts - plan_enter/exit pattern:
packages/opencode/src/tool/plan.ts
Reacted by Santiago M. Mola and Manuel Kehl
Reacted by Wil (₩) Moore III
Metadata
Metadata
Assignees
Labels
No labels
Activity
[-]plugin/tui: allow plugins to switch active primary agent (custom primary agent handoff)[/-][+][FEATURE]: allow plugins to switch active primary agent (custom primary agent handoff)[/+]github-actions commentedon Feb 21, 2026
Thanks for updating the issue! It now follows the contributing guidelines and looks great. We appreciate the clear description and references to the relevant code.
github-actions commentedon Feb 21, 2026
Thanks for updating the issue! It now follows our contributing guidelines. Your feature request is clear and well-structured. We appreciate the detailed context and the code references.
wilmoore commentedon Mar 5, 2026
+1 — this unlocks a big safety/UX workflow for me even with built-in agents.
Use case: “auto-return to Plan” safety rail
I use
planas my default to avoid unintended edits, but I switch tobuildtemporarily to execute changes. The problem is I often forget I’m still inbuildand send the next prompt assumingplan, which can immediately start editing/running commands.This prevents accidental edits/commands by making Plan the “sticky default” after any Build interaction.
Today I can almost solve this with a plugin, but it’s brittle:
build, immediately switch the active agent back toplanfor the next prompt…but the missing primitive is exactly what this issue proposes: a deterministic, first-class way for plugins to set the active primary agent in the TUI.
Request
Please add a plugin-accessible, deterministic “set active agent by name” mechanism (your
tui.agent.set { name }proposal is perfect).This should:
Bonus (makes plugins more robust)
Bonus: emit
tui.agent.updated { name }(or expose acurrentAgent()API) so plugins can avoid redundant toggles and verify state.This would let safety plugins implement “Plan-by-default” reliably without relying on
agent.cycleordering.github-actions commentedon Jul 4, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.