Feature request: .ocdx renderer bundle support for third-party GUI extensions

Feature request: `.ocdx` renderer bundle support for third-party GUI extensions

Current behavior (retail builds)

Installed third-party .ocdx extensions only run their main entry; the renderer side only loads built-in extensions. The settings page states this explicitly: "Built-in GUI extensions in this window. Development builds only." There is also no install UI for third-party extensions in retail builds.

This means a third-party extension can contribute main-process capabilities (menubar items, IPC) but cannot contribute any window-side UI (panels, slots, settings pages) in a retail build.

What we built and verified (dev build)

We implemented a built-in extension (open-gen-ui) in a dev build that renders agent-generated interactive HTML in a side panel:

React island: the extension's SolidJS panel mounts a React 19 subtree (react-dom/client createRoot) hosting the OpenIntelligentUI renderer layer (Idiomorph + @jetbrains/websandbox sandboxed iframe).
Full chain verified end-to-end: agent generates an HTML document via an MCP tool → turn-end event (session.execution.succeeded) → panel auto-opens → React island mounts → websandbox iframe renders the widget (charts and tables verified). Manual entry points (a session.panel MenuItem and a Command) also work.
Screenshots of the running extension (settings page showing open-gen-ui = Active, rendered widgets) are available on request.

The implementation required only: a vite config tweak (solidPlugin exclude for the React files), react/react-dom/@jetbrains/websandbox as dependencies, and standard Extension.define registration. Nothing exotic — the SDK already supports everything needed on the dev side.

Request

Support renderer bundles in the .ocdx format so third-party extensions can contribute window-side UI (panels/slots/settings pages), not just main-process capabilities. Concretely:

Allow an .ocdx archive to ship a renderer bundle that the host loads like built-in extensions do.
Provide an install path in retail builds (the install() bridge exists in shipped code but has no UI).

Why it matters

The generative-UI use case (CopilotKit/OpenIntelligentUI style: agent output rendered as interactive charts/tables/diagrams instead of plain markdown) fundamentally needs renderer-side rendering of agent output. Today this is only possible by patching the app or running a dev build — neither is viable for end users. With .ocdx renderer support, this whole class of extensions becomes distributable.

We're happy to share the dev-build implementation, screenshots, or upstream the extension itself if that helps move this forward.

Thanks for the detailed write-up and for testing the full chain in a dev build!

In short, you're asking for third-party desktop extensions to be able to contribute window-side UI (panels, slots, settings pages) in retail builds, not only main-process features. You suggest doing this by letting .ocdx archives ship a renderer bundle and by adding an install path for them. Today the renderer only loads built-in extensions by design. The extension manager calls .ocdx installs groundwork that runs only the main entry for now, and packaged builds won't use it until installs have a trust model.

Related work you may want to follow:

feat(plugin): add OpenCode Desktop GUI plugins #55246: open PR that lets plugins listed in opencode.json ship a GUI part through a ./gui-experimental package export. It also removes the unshipped .ocdx installer, so this may be how third-party GUI code ends up being distributed instead of .ocdx.
[FEATURE]: Plugin UI surface for the web/desktop app, mirroring the TUI plugin API #43132: open request for a plugin UI surface in the web/desktop app, mirroring the TUI plugin API
[FEATURE]: Desktop app: user-installable GUI plugins, incl. a startup/boot animation slot #56037: open request for user-installable GUI plugins (startup animation use case)
[FEATURE]: Plugins that can modify the UI for desktop #51579: earlier request for plugins that can change the desktop UI, e.g. to show generated images in chat

Your generative-UI extension sounds like a good real-world test for whichever approach lands. Maintainers will consider this.

Related, but a different piece of the problem — filing for the chat-timeline case so it does not get lost here.

This issue is about distribution of renderer bundles to third-party extensions. The gap I hit is the chat timeline: a plugin that produces an interactive HTML artifact (a Chart.js chart, a self-contained HTML file) cannot get it rendered inline in a conversation, so the user has to leave the chat and open a file.

The relevant detail: Desktop 2.1.2 already renders .html files live in the Files-panel artifact viewer — a blob-URL <iframe sandbox="allow-scripts allow-popups allow-forms allow-modals">, no allow-same-origin. So the rendering primitive exists; it is just not reachable from a message, and a plugin has no way to contribute a custom part renderer to the chat.

Filed as #57818.

Navigation Menu

Repository navigation

Feature request: .ocdx renderer bundle support for third-party GUI extensions #57619