Repository navigation
Plugin tools should respect metadata title in TUI display #18585
Description
Problem
Plugin tools always display as toolname [args] or toolname JSON.stringify(input) in the TUI, even when the tool sets a custom title via context.metadata({ title: "..." }).
Expected Behavior
When a plugin tool calls context.metadata({ title: "custom title" }), the TUI should display the custom title instead of the raw tool name + args.
For example, a go-task plugin tool named task_run that sets:
context.metadata({ title: "test" })Should display as:
task_run test
Instead of:
task_run [task=test]
Or ideally, allow the title to fully replace the display:
task test
Current Behavior
The TUI ignores the state.title set by context.metadata() and always shows the tool name + JSON-stringified input args.
Context
Looking at the source:
packages/opencode/src/cli/cmd/run.tshas afallback()function that checksstate.title- However, this appears to be for CLI mode, not the interactive TUI
- Built-in tools like
bash,read,globhave custom rendering that shows clean output - Plugin tools fall through to generic rendering
Proposed Solution
- In the TUI, check
state.titlefor plugin tools and use it when present - Consider allowing plugins to fully override the display (just show title, not
toolname title)
Environment
- OpenCode version: 1.2.27
- Platform: Linux
Use Case
Building a go-task plugin that wraps task commands. Want task_run to display as task test rather than task_run [task=test] for a cleaner UX that matches how the underlying command looks.
Activity
github-actions commentedon Mar 22, 2026
This issue might be a duplicate of existing issues. Please check:
fromPluginwrapper discards custom metadata set by plugin tools viacontext.metadata()#12527:fromPluginwrapper discards custom metadata (includingtitle) set by plugin tools viacontext.metadata()— this covers the same root cause where thefromPluginwrapper hardcodes the returned metadata, discarding any title set during execution, which explains why the TUI never shows the custom title.gotgenes commentedon Mar 30, 2026
Additional context: there's an asymmetry in how
state.titleis consumed between the parent session view and the subagent's own view.The
Taskcomponent in the TUI (packages/opencode/src/cli/cmd/tui/routes/session/index.tsx) does readstate.titlefrom the subagent's tool parts and renders it as a live subtitle:But if you navigate into the subagent session, the same
ci_watchtool part renders viaGenericTool→InlineTool, which ignoresstate.titleentirely and just shows the static input args:So the data is there and flowing correctly —
context.metadata({ title })writes tostate.title, themessage.part.updatedevent fires, and the reactive store updates. TheTaskcomponent reads it. ButGenericTool/InlineTooldon't.The fix would be in
GenericTool(orInlineToolmore broadly) to check forstate.titleon running parts and display it — either replacing or supplementing the raw input display.malhashemi commentedon May 29, 2026
Hit this same wall building a
workfloworchestrator plugin that fans out subagents viasession.create({ parentID }). Confirming it's broader than the title — the whole renderer is gated on the tool name, in both frontends:cli/cmd/tui/feature-plugins/system/session-v2.tsx): a<Switch>onprops.part.name(task→ the rich<Task>card, everything else →<GenericTool>), andGenericToolreads neitherstate.titlenorstate.metadata.packages/ui/src/components/message-part.tsx):ToolRegistry.render(part().tool)plus threeif (part().tool !== "task") returnguards.Since a plugin tool's name is fixed to its
Hooks.toolkey, nothing it emits can reach thetaskrenderer.ctx.metadataalready reaches the running part (session/tools.ts:50-63), so this is purely a renderer-selection gate, not a data gap.Minimal fix that also resolves #20184: select the subagent renderer by a metadata marker rather than the literal name — route any tool part whose
state.metadatacarriessessionId(orkind:"subagent") to the existing task widget, withtasksetting the marker itself. No new render API,taskbehaviour unchanged, and any plugin opts in via the existingctx.metadatachannel. (AsessionIds[]variant would let one part represent a fan-out of several children.)github-actions commentedon Jul 29, 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.