Repository navigation
[FEATURE]: Opt-in Control Hub layout: thread matrix, skills/context inspector, execution graph #50606
Description
OpenCode's current Desktop UI is exceptional for fast, focused pair-programming sessions. Switching models and providers already has real dialogs (model, provider, MCP and server pickers), so the gap isn't that those actions need commands — it's that state about what is running, what it's costing, and what is loaded isn't visible on screen, and digging through logs or expanding projects one at a time to find out is the part that hurts. Its ultra-minimalist design lacks visibility and orchestration tools when dealing with complex, long-running agent loops or cross-provider workflows.
A major UX upgrade for OpenCode Desktop that retains its clean, developer-first philosophy while adding an opt-in Control Hub Layout — off by default, so the current experience is untouched. This proposal introduces three core UI modules.
1. Visual Agent & Session Matrix (Left Sidebar Expansion)
Parallel Thread Visualizer: A unified sidebar showing active, queued, and background tasks running across local or remote OpenCode server instances (opencode-cli). (Relates to #44760 "opencode join" — hub-managed node fleet — and #47692 OpenCode Remote Control, which is the fleet direction this should compose with rather than duplicate.)
Model & Provider Quick-Dock: A persistent status ribbon showing active model provider latencies, token consumption, and instant inline toggles for provider variants (e.g. Anthropic, Bedrock, Ollama/LM Studio). Desktop's status popover already surfaces context usage, so this extends it rather than starting over; #50000 already asks for live tokens/sec in TUI and Desktop, which should be one implementation rather than two.
2. Persistent Context, Memory & Skill Inspector (Collapsible Right/Bottom Drawer)
Skill / Extension Manager UI: A graphical dashboard for .opencode/plugins and skills — allowing developers to inspect loaded tools, toggle active execution permissions, and view dynamic skill outputs. A plugin manager already exists in the TUI (#47345 notes it has no slash command and is effectively undiscoverable); this would be the Desktop equivalent, alongside #41037 (plugins + LSP servers via GUI) and #48355 / #32954 / #48101 / #28696 for skills. It should also expose what permission-auto-respond is currently allowing silently.
Session Knowledge & Graph Inspector: A visual drawer showing auto-indexed project context and pinned workspace constraints (rules/prompts) without needing to manually edit opencode.jsonc. OpenCode has no memory variables today, so this covers what does exist — AGENTS.md, project and global config, loaded skills, injected rules — with the token cost of each, editable in place instead of hand-editing config and restarting. A persistent cross-session memory store would be a separate proposal.
3. Execution Topology & Diff Workbench (Center Workspace)
Interactive Plan & Execution Graph: A visual toggle above the chat view that renders OpenCode's Plan Mode step-by-step logic as an interactive node flow before code modifications begin.
Multi-Tab Preview & Artifact Space: An updated artifact/preview pane capable of split-viewing live web render targets (HTML/CSS/JS), structural file trees, and granular inline git diff approvals simultaneously. Desktop already has an embedded browser (#50382 tracks a cookie-persistence bug in it), so the gap here is docking a live render target as a pane beside review rather than adding browser support from scratch; and the session side panel composes review, terminal and files as tabs rather than side by side. Related: #26772, #41361.
Why this belongs in OpenCode
Plugins can already contribute UI to the TUI (@opencode-ai/plugin/tui exposes opentui slots, renderables and keybinds), but there's no equivalent extension surface for packages/app — the Desktop and web UI — so a hub like this can't be shipped as a plugin today. It also needs runtime state the app can only get from the server: sessions across server instances, pending permissions, and provider health.
Activity
github-actions commentedon Sep 22, 2026
This issue might be a duplicate of (or significantly overlap with) existing issues. Please check:
You've already linked several related issues in the body, which is great. The above are additional ones that may warrant consolidation or cross-referencing.
zperel-2nd-account commentedon Sep 22, 2026
Reviewed all four. Verdicts, then the ones the bot didn't catch, then two corrections I made to the body after checking.
#27995 (Agent Activity Panel) — real overlap with module 1. I'd rather compose with it than have two panels. Scope difference: #27995 monitors background-dispatched agents with live per-task output (a pull model via
background_output), while module 1 is about sessions and worktrees across server instances, including queued and idle ones, with Desktop as the surface. If you want one issue, #27995 is older and more specific — I'm happy to fold module 1 into it, or narrow mine to the cross-server/queued dimension and leave agent-activity monitoring to that issue.#48956 (persistent left sidebar) — same direction, and it belongs to a bigger cluster I should have referenced. That cluster is #37012 (keep legacy layout, 49 comments), #48882 (restore legacy sidebar as an option, 24), #48837 (V2 hurts multi-project/multi-agent workflows), #48966, #37273. Worth separating the two asks: those are about navigation — getting the project/workspace/session tree back. Module 1 is about state — which threads are running, what they cost, what they're waiting on, on which server. Even with the legacy sidebar restored, there's still no aggregation of live agent state across servers, so module 1 should be read as compatible with whichever layout wins rather than as a vote in that debate.
#25262 (toggleable top-bar status header) — adjacent, different surface. That one is TUI-scoped (the sidebar column vanishes on narrow terminals) and asks for session title, context, cost, MCP/LSP and git branch in a strip. Module 1's quick-dock is Desktop and adds provider latency plus inline variant switching. They converge on one decision worth making once: should session state live in a single persistent strip shared by TUI and Desktop? #50000 (tokens/sec in both) points the same way.
#41908 (/context per-component breakdown) — closest to a straight duplicate of module 2b. Same data (system prompt, tool definitions, messages, cache as separate rows with token counts and % of limit), different surface: theirs is a
/contextcommand in the TUI, mine is a Desktop drawer. Per-component accounting should be one implementation — if you'd prefer, module 2b folds into #41908 and I'll drop it from here.Three the bot didn't flag that I should have linked myself:
Two corrections I've just made to the body, because checking these contradicted what I'd written: I claimed there was no preview target at all (wrong — see #50382), and I described the skills/plugin manager as if nothing existed (wrong — the TUI has one, per #47345).
If you want it narrower: folding 2b into #41908 and module 1's navigation half into #48956/#37012 leaves this issue scoped to what I don't believe exists anywhere yet — cross-server thread aggregation, the Desktop-side capabilities/permissions inspector, and the plan-graph plus preview workbench. Say the word and I'll rewrite the body that way; I'd rather it be small and real than broad and duplicative.
opencodejr commentedon Oct 28, 2026
Thanks for the detailed proposal! In short, you're asking for an opt-in "Control Hub" layout in Desktop: a sidebar showing sessions across server instances, a model/provider status ribbon, a drawer to inspect skills, plugins, permissions and loaded context (with token costs), and a visual plan/execution graph next to a side-by-side preview and diff workbench. Maintainers will consider it.
One correction: Desktop and web do now have a plugin extension surface. There is an experimental GUI plugin SDK,
@opencode/plugin/gui, which plugins ship as a./gui-experimentalbundle. It's the same SDK the built-in terminal, review, files and browser features use. You can register commands, side panels, settings pages and titlebar items, and render into a few slots: the bottom of the window, the session header and the end of the side panel's tab strip. Seepackages/gui-plugins/README.md.So parts of this, like a context/skills inspector panel or a status strip, could be prototyped as a plugin today. Other parts would need more from the SDK: for example a left-sidebar slot, a slot above the chat timeline for a plan graph, and a way to collect sessions and pending permissions from several servers.
Related issues you mentioned:
opencode join— hub-managed node fleet with centralized session discovery #44760: remote control and a hub-managed node fleet