[FEATURE]: Add Support for MCP Apps in the desktop app #10884

Activity

1. NourEldin-Osama

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Jan 27, 2026
2. github-actions

   assigned

   adamdotdevin

   on Jan 27, 2026
3. github-actions

   added

   webRelates to opencode on web / desktopRelates to opencode on web / desktop

   on Jan 27, 2026
4. github-actions commented on Jan 27, 2026

   

   github-actionsBot

   on Jan 27, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • [FEATURE]: Generic UI Intent Channel for cross-client plugin-driven UX #6330: [FEATURE]: Generic UI Intent Channel for cross-client plugin-driven UX - This discusses infrastructure for rendering rich UI (forms, dialogs, etc.) across TUI, Desktop, and Web clients, which could be foundational work for MCP Apps support.

   Feel free to ignore if this doesn't address your specific case.

   👎React with 👎4Reacted by Bartosz Łukowicz, Jeppe Reinhold, NourEldin Osama and wesleydonk
5. JReinhold commented on Jan 31, 2026

   

   JReinhold

   on Jan 31, 2026

   More actions

   The announcement of the stabel release of the MCP Apps spec lists other clients' support, and it would be great to see Opencode in this list.

   • VSCode
   • Claude Desktop
   • ChatGPT

   https://blog.modelcontextprotocol.io/posts/2026-01-26-mcp-apps/

   👍React with 👍7Reacted by NourEldin Osama, Mykhaylo Ryechkin, Josh, Lukas Mosser, Vernon Stinebaker, Sam700n and wesleydonk
6. JairajSustained commented on Feb 13, 2026

   

   JairajSustained

   on Feb 13, 2026

   More actions

   If this gets implemented, we could use excelidraw mcp server visually.

   👍React with 👍11Reacted by Khue Doan, Trevor Hartman, Matthew Fitzpatrick, Tristan Stahnke, Angel Loredo, Nathnael Desta, ilyes, Sam700n, Pavlo Osadchyi, João Albuquerque Barbosa and 1 more
7. MarcSkovMadsen commented on Mar 2, 2026

   

   MarcSkovMadsen

   on Mar 2, 2026

   Last edited by MarcSkovMadsen

   More actions

   I would like to visialize anything using pyodide and python ecosystem provided by https://panel-extensions.github.io/panel-live/tutorials/getting-started-mcp/
8. tristan-stahnke-GPS commented on Mar 4, 2026

   

   tristan-stahnke-GPS

   on Mar 4, 2026

   Last edited by tristan-stahnke-GPS

   More actions

   @MarcSkovMadsen @JairajSustained : Can you see if my PR works for your use case?
9. vvcb commented on Mar 31, 2026

   

   vvcb

   on Mar 31, 2026

   More actions

   Prefect are working on Prefab (https://prefab.prefect.io/docs/welcome) which looks fabulous and is worth investigating for integration here.
10. thdxr

    removed

    discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

    webRelates to opencode on web / desktopRelates to opencode on web / desktop

    on May 3, 2026
11. ilyes-i-ben commented on May 7, 2026

    

    ilyes-i-ben

    on May 7, 2026

    More actions

    +1
12. takeseem commented on Jun 3, 2026

    

    takeseem

    on Jun 3, 2026

    More actions

    玩呢，还没支持 mcp
13. MaxiWeissenbacher commented on Jun 10, 2026

    

    MaxiWeissenbacher

    on Jun 10, 2026

    More actions

    +1
14. amirsaam commented on Jun 25, 2026

    

    amirsaam

    on Jun 25, 2026

    More actions

    +1
15. adrian-pattz commented on Aug 4, 2026

    

    adrian-pattz

    on Aug 4, 2026

    More actions

    +1, this is a big missing feature

    👍React with 👍5Reacted by ciso-adesso, Luana Ritter, Lukas, adrian-pattz and jmtemmos
16. iwiznia commented on Aug 24, 2026

    

    iwiznia

    on Aug 24, 2026

    More actions

    +1, this is a complete deal breaker for the desktop app.
17. sofianbll commented on Oct 20, 2026

    

    sofianbll

    on Oct 20, 2026

    More actions

    Hi @adamdotdevin (cc @jlongster for #53514) — following up on this issue and on @thdxr's request in #15926 to port MCP Apps to V2.

    Before opening anything, I'd like design feedback on a small engine-only first increment. I built it as a throwaway local proof against dev (6bac3b9) so the discussion has something concrete behind it:

    Proposed engine contract (no iframe/UI code in the engine)

    1. Preserve MCP Apps data on the terminal tool part under state.metadata.mcp (toolMeta, resultMeta, structuredContent, and ui: { resourceUri, mimeType, html, meta }). Model lowering reads state.content, so the UI payload never reaches the model; embedded ui:// HTML is removed from model-visible content.
    2. Resolve the app only for ui:// URIs with text/html;profile=mcp-app, via the same server connection, behind the existing opencode_read_mcp_resource permission.
    3. A session-scoped callback POST /api/session/:sessionID/mcp/call ({ server, tool, arguments, messageID }) that reuses permission.assert with the originating message's agent — no raw Mcp.Service.callTool bypass; denial → 403, never a silent call.

    What the local proof shows (patches + reproducible CI): a model tool call renders an MCP App (an OpenUI counter) in a patched OpenChamber client, a click calls the server back through (3), a visible permission prompt can deny (no MCP call reaches the server) or approve, and the host CSP blocks undeclared network access — on web (Playwright CI) and once on macOS Electron.
    Proof, patches and full proposal: https://github.com/sofianbll/opencode-standards-proof (see PROOF.md and proposals/opencode-mcp-apps-v2.md).

    Not claimed: this is not a released API, not full MCP Apps conformance, callback results are not persisted to history yet, and app-only tool visibility is not handled.

    Questions

    • Should [FEATURE]: Add Support for MCP Apps in the desktop app #10884 and [FEATURE]: let plugins call tools and read resources on the engine's MCP connections #53514 share this engine layer, and who should own the V2 design after feat: add MCP Apps support for rich iframe UIs #15926?
    • Is a UI-only metadata namespace + session-scoped callback the shape you want, or would you prefer another V2 API? Eager vs lazy HTML?
    • How should UI-initiated calls appear in audit/history?

    Happy to adapt or drop this — I won't open a PR without a go-ahead per CONTRIBUTING.
18. opencodejr commented on Oct 29, 2026

    

    opencodejrBot

    on Oct 29, 2026

    Contributor

    More actions

    Thanks for the request! You're asking for the OpenCode desktop app to host and render MCP Apps: interactive UIs that MCP servers provide through ui:// resources, shown in the app instead of only text or Markdown.

    The current v2 code doesn't support this yet. It also can't be added as a plugin right now, because plugins can't render UI in the desktop app or read resources from MCP servers. Maintainers will consider it.

    Related issues and PRs:

    • feat: add MCP Apps support for rich iframe UIs #15926: an earlier PR adding MCP Apps support with iframe UIs (closed without merging; a later comment here says it was asked to be ported to V2)
    • [FEATURE]: let plugins call tools and read resources on the engine's MCP connections #53514: lets plugins call tools and read resources on the engine's MCP connections, which would be one building block for this
    • [FEATURE]: Generic UI Intent Channel for cross-client plugin-driven UX #6330: a shared channel that plugins could use to show rich UI across the TUI, desktop and web clients
19. balabommablock-cpu commented on Nov 1, 2026

    

    balabommablock-cpu

    on Nov 1, 2026

    More actions

    @sofianbll's engine-first split looks right to me: engine keeps the data and the permission check, clients decide how to draw it. A few product calls that are cheap to make now and painful to change later:

    1. The same session in the TUI. OpenCode is terminal-first, and one session gets opened from TUI, desktop and web. A tool with an app still returns normal text content, so the TUI shows that, plus one line: Interactive view available: open in desktop or web. Nobody should open a session in the terminal and find a blank tool part.

    2. Don't save the HTML, save the pointer. The proposal stores ui.html in state.metadata.mcp. I'd keep resourceUri and the tool result, and fetch the HTML again when the part is drawn. Saved HTML grows every session file and goes stale when the server updates. If the server isn't connected later, show the text result and Excalidraw app unavailable (server not connected).

    3. Say who's asking. Callback (3) reuses permission.assert, which is good. The prompt should also say the call came from the app, not the model: Excalidraw app wants to run export_scene. Same rules, different sentence. Otherwise a click inside an app looks like the agent going off on its own.

    4. Nothing reaches the model quietly. Apps can send messages and update the model's context. For v1 I'd either skip those, or show each one in the thread (From Excalidraw app: …) before the model sees it. A third-party iframe adding hidden context is the kind of thing that's hard to take back once people rely on it.

    5. Smallest v1: render inline in desktop and web with a height cap and a "pop out" button, app tool calls through the existing permission check, TUI fallback line. Later: preloading, streaming tool input into the app, app messages.

    None of this changes your engine contract much. Mostly it's point 2 (pointer instead of HTML) and an origin: "app" field on the callback so point 3 is possible.