[FEATURE]: Render plugin-supplied interactive HTML/JS inline in the Desktop chat #57818

Activity

1. opencode-agent commented on Oct 21, 2026

   

   opencode-agentBot

   on Oct 21, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed request, @teodor-georgiev. You're asking for a way for a plugin's tool to attach a self-contained HTML/JS artifact, such as an interactive chart, and have the Desktop app render it inline in the conversation. It would be sandboxed the same way the Files-panel artifact viewer already sandboxes .html files, with the app owning the frame.

   As you found, a plugin can't do this today. Plugins have no hook into the chat renderer: tool cards are hard-coded, and file parts in tool results aren't shown in the message bubble. So this needs a change in the app itself, for example a tool-result HTML part that the session UI renders in the existing sandboxed iframe. Maintainers will consider it.

   Related issues, most relevant first:

   • [FEATURE]: Desktop inline conversation visualizations #40583 / feat(desktop): add inline conversation visualizations #40582: Desktop inline conversation visualizations in a sandboxed iframe (closed without a maintainer decision)
   • [FEATURE]: render SVG/HTML artifacts inline in chat #25076: render SVG/HTML artifacts inline in chat (closed as stale)
   • [FEATURE]: Add Support for MCP Apps in the desktop app #10884: MCP Apps support in the Desktop app (open, the same rendering need via MCP)
   • [FEATURE]:Feature Request: UI Plugin API for rendering custom components in message parts #20034: UI plugin API for custom message-part components (closed)
   • [FEATURE]: Generic UI Intent Channel for cross-client plugin-driven UX #6330: generic UI intent channel for plugin-driven UI (open)
   • Feature request: .ocdx renderer bundle support for third-party GUI extensions #57619: renderer bundles for third-party GUI extensions (side panels)
   • feat(app): add generative UI to the GUI #54747: generative UI with built-in components (beta only)
   • [FEATURE]: Interactive /visualize command with multi-target diagramming #48585, [FEATURE] Desktop: "screenshot / mockup → working code" workflow with built-in live preview (like CUE / code-to-UI) #41361: adjacent visualization and preview requests
2. Dante-dan commented on Oct 22, 2026

   

   Dante-dan

   on Oct 22, 2026

   Contributor

   More actions

   A bounded first step could use the existing tool-result file content rather than a plugin-supplied renderer:

   • Tool.Content already carries uri, mime, and name. Add an explicit inline-artifact presentation marker for self-contained text/html results, preserving the ordinary text/file fallback. The current currentToolOutput extracts only text before passing it to the tool display; that is a concrete place where the artifact gets lost from presentation.
   • Extract a shared, app-owned HTML frame from ArtifactFrame, with blob cleanup and a bounded inline viewport. Keep the markdown sanitizer unchanged. The current viewer permits scripts, popups, forms, and modals without allow-same-origin; for inline charts I would start with only allow-scripts, no host callbacks, and no arbitrary remote URLs.
   • Treat “no network” as a separate requirement: an opaque-origin sandbox alone does not enforce it. Before shipping, verify the host-controlled CSP/network and navigation restrictions on Desktop, including blocked loopback/sidecar access and no inherited app credentials. Test a bundled chart, history reload, malformed/oversized payload fallback, blob cleanup, and unchanged script stripping in ordinary markdown.

   This would cover local-plugin charts without adding MCP Apps callbacks or an arbitrary UI plugin API. The engine contract discussed in #10884 should inform the presentation marker so the two paths can share a renderer later.

   Could a maintainer approve this direction, or indicate whether inline HTML should instead wait for the MCP Apps host design?