Repository navigation
[FEATURE]:Frontend UI extensibility for plugins (Custom Settings & Dialogs) #19919
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Is your feature request related to a problem? Please describe.
Currently, the @opencode-ai/plugin architecture is exclusively backend-focused (Node/Bun). While it provides excellent support for intercepting lifecycle hooks, registering commands/tools, and modifying configurations, it completely lacks mechanisms for frontend UI extensibility.
A concrete example of this limitation arises when attempting to refactor the built-in experimental war agent into a standalone plugin to clean up the core codebase. The backend logic and prompts can be successfully migrated via the config hook. However, the plugin loses its dedicated settings UI (dialog-war-config.tsx) and specific trigger buttons (prompt-input.tsx) because plugins cannot currently inject custom SolidJS components or HTML into the frontend.
The only workaround right now is hardcoding agent-specific UI logic directly into the core packages/app repository. This tightly couples the code and defeats the purpose of having a modular plugin system. Furthermore, while MCP (Model Context Protocol) is fantastic for exposing tools and context, it does not address these client-side UI rendering limitations.
Describe the solution you'd like
I would love to see a frontend extensibility mechanism introduced into the plugin architecture. Here are a few potential approaches, ranging from highly flexible to highly secure:
Micro-frontend / Dynamic Component Loading: Allow plugins to bundle a ui.js module that exports standard SolidJS components or Web Components. The core app could dynamically import() these and provide specific mounting points (e.g., registerSettingsTab, registerAgentConfigDialog).
Iframe / WebView Injection (Safest & Simplest): Allow plugins to expose an endpoint or a static HTML file. The frontend could provide a hook like registerWebviewPanel(id, url) and render an <iframe> within the settings dialog or side panel. This ensures complete decoupling and sandbox security.
Schema-driven UI Generation: If running arbitrary third-party code on the frontend is a security concern, plugins could return a JSON Schema describing their required configuration fields (e.g., dropdowns for commanderModel, editModel). The frontend could then dynamically render a generic, native-looking form based on this schema.
Describe alternatives you've considered
Modifying .opencode.json directly: Users have to manually edit the JSON file to change plugin-specific settings. This offers a significantly poorer user experience compared to native UI dropdowns and toggles.
Tool-based configuration: Exposing a configure_agent tool and asking the AI to change the settings for the user. While functional, it is much slower and less deterministic than a simple UI interaction.
Forking the repository: Maintaining a hardcoded fork of packages/app strictly to preserve custom UI components for proprietary or experimental agents.
Additional context
Frontend UI extensibility is the missing piece for a truly modular Opencode ecosystem. Implementing this would empower developers to build rich, interactive plugins—such as custom agent dashboards, specialized workflow visualizations, and seamless third-party integrations—without perpetually bloating the core application repository.
Activity
github-actions commentedon Mar 29, 2026
This issue might be a duplicate of existing issues. Please check:
Nihalmai commentedon Mar 30, 2026
I built a working proof of concept for this a complete UI rendering plugin for OpenCode that renders weather cards, charts, tables, metrics, forms and more inline in chat.
Repo: https://github.com/Nihalmai/opencode-plugin-update
Currently works as a fork with only 3 lines changed in OpenCode source. Would love to see an official plugin API so this can be fully external. Happy to contribute.
UR-xiaoyang commentedon Apr 5, 2026
Thanks for sharing this! It's a cool PoC and shows the potential of in-chat UI.
However, my vision is slightly different. I believe plugins should be more than just 'prompt-engineered UI elements' rendered by the LLM. I want to build a true 'Platform' where plugins can:
Customize the UI: Render native components (tables, charts, forms) directly in the interface, not just as text/markdown blocks.
Add New Functionality: Introduce entirely new capabilities (like a weather card or metrics dashboard) that feel like first-class citizens in the app.
Be Fully External: Work without forking the core source code.
This requires a robust Plugin API that allows for native UI extension.
Nihalmai commentedon Apr 7, 2026
Thank you for looking at my work.
You're absolutely right. What I built is more of an experiment, the AI is told what format to output, and my fork renders it as UI. It works, but it's not a real plugin system.
What you're describing is the proper solution, where plugins can add real UI components without touching the core code at all. That's exactly what I was hoping for too when I built this.
I'd love to see that happen, and I'm happy to help in any way I can. Our goals are the same.
Hope the maintainers pick this up soon!
github-actions commentedon Jul 3, 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.
liudongyan13701205717-source commentedon Aug 14, 2026
Re-pitching this, because the motivation has become concrete since it was closed as not_planned.
Concrete demand now exists: users increasingly expect agent UIs like Tencent's Marvis "virtual office" — anthropomorphized multi-agent workspaces with avatars, live status, and task-progress visualization. That entire class of experience is impossible to build as an OpenCode plugin today, because the
@opencode-ai/pluginAPI is backend-only (hooks / tools / commands) with no way to mount a custom UI surface.Feasibility is already proven:
Nihalmai/opencode-plugin-updaterendered weather cards / charts / forms inline with only a ~3-line core change. The rendering path exists; what's missing is a supported, external plugin API.A minimal, safe API would unblock a large category of plugins:
registerWebviewPanel(id, url)→ render a sandboxed iframe/WebView in a side panel or settings dialog (lowest risk)This isn't "prompt-engineered UI in chat" — it's letting plugins become first-class UI citizens (dashboards, agent visualizations, native settings) without forking core. As rich agent frontends become table stakes, reconsidering #19919 would unlock a lot of ecosystem value.
Happy to help specify the API or prototype the iframe/webview path.