Codex Desktop does not render MCP Apps inline UI resources even when tool result includes mcp_app_resource_uri

Open 💬 11 comments Opened May 4, 2026 by code-cheers

Summary

Codex Desktop currently appears able to call MCP tools, but it does not render MCP Apps inline iframe UI resources.

A minimal MCP App tool returns a valid mcp_app_resource_uri and _meta resource URI fields, but Codex Desktop never appears to call read-mcp-resource, so the inline UI is not rendered.

Can you confirm whether MCP Apps inline UI is currently supported in Codex Desktop, and if not, when it is expected to be supported?

Environment

Codex Desktop: 26.429.30905
Bundled Codex CLI/runtime: codex-cli 0.128.0-alpha.1
macOS
MCP server: local stdio server
features.apps = true
features.enable_mcp_apps = true was also tested

Reproduction

a tool: show_minimal_inline_app
a resource: ui://minimal-inline/hello.html

The tool returns a successful result with:

{
  "structuredContent": {
    "title": "Minimal MCP Inline App",
    "inline_resource_uri": "ui://minimal-inline/hello.html"
  },
  "_meta": {
    "ui/resourceUri": "ui://minimal-inline/hello.html",
    "ui.resourceUri": "ui://minimal-inline/hello.html",
    "openai/outputTemplate": "ui://minimal-inline/hello.html",
    "openai/resultCanProduceWidget": true,
    "openai/widgetAccessible": true,
    "ui": {
      "resourceUri": "ui://minimal-inline/hello.html"
    }
  }
}

Codex session logs show:

mcp_app_resource_uri: ui://minimal-inline/hello.html

However, Codex Desktop does not render an inline iframe UI and no read-mcp-resource / resource read is observed.

Expected behavior

When an MCP tool result includes a valid MCP App resource URI, Codex Desktop should read the MCP resource and render it inline as an iframe/app UI.

Actual behavior

The MCP tool call succeeds and the session log contains mcp_app_resource_uri, but the Desktop UI only shows the textual tool result. No inline app UI is rendered.

Additional investigation

I inspected the current Desktop bundle and found that MCP Apps rendering appears to be gated by enable_mcp_apps / renderMcpApps.

The public Codex docs mention features.apps, but I could not find public documentation for features.enable_mcp_apps.

The OpenAI Codex repo has PR #19884, "Add MCP app feature flag", which adds enable_mcp_apps as an under-development feature disabled by default:
https://github.com/openai/codex/pull/19884

This suggests MCP Apps inline UI may currently be behind an internal/product gate, even though MCP tools and resources are otherwise available.

Question

Is MCP Apps inline UI currently supported in Codex Desktop?

If it is intentionally gated or temporarily disabled, is there a documented way to enable it locally, or an expected release/version where it will be supported?

View original on GitHub ↗

11 Comments

ilyes-i-ben · 2 months ago

phernandez · 2 months ago

I can reproduce this with a FastMCP/Prefab MCP Apps POC, and I have a useful cross-client comparison that points to the Codex Desktop render/resource hydration path rather than the MCP server payload.

Environment / server:

Codex CLI/runtime: codex-cli 0.130.0
macOS
features.apps = true
features.enable_mcp_apps = true enabled, with the under-development warning shown at Codex startup
MCP server: local stdio server
Server stack: fastmcp==3.3.1, prefab-ui==0.18.0
Tool tested: read_note_app

The tool descriptor exposed to Codex includes the expected app metadata:

{
  "ui": {
    "resourceUri": "ui://prefab/tool/fdb0eb60723f/renderer.html",
    "visibility": ["model", "app"]
  },
  "ui/resourceUri": "ui://prefab/tool/fdb0eb60723f/renderer.html",
  "openai/outputTemplate": "ui://prefab/tool/fdb0eb60723f/renderer.html",
  "openai/widgetAccessible": true,
  "openai/visibility": "public"
}

The server also advertises the matching resource:

ui://prefab/tool/fdb0eb60723f/renderer.html text/html;profile=mcp-app

Result:

ChatGPT renders the app inline when connected to the same server over an HTTPS /mcp tunnel.
Claude Desktop renders the app inline when connected to the same local stdio server.
Codex discovers the tools and calls read_note_app successfully, but the chat surface displays the raw $prefab JSON payload rather than rendering the app iframe/component.

So this looks consistent with the issue description: Codex receives enough metadata to identify the MCP App resource, but the Desktop UI does not appear to hydrate/render the app resource yet.

This POC also exercises expandable frontmatter, markdown rendering, observations, and relations, so it is not just a bare hello-world resource. Happy to provide a minimal repro if useful.

japboy · 1 month ago

I've just confirmed that Codex Desktop could show my MCP Apps (w/o proper CSP support though)

Jerrynet · 1 month ago

I've using the official @modelcontextprotocol/ext-apps example build for testing:

version 26.519.81530 can render inline MCP Apps correctly
version 26.527.30818 broken
version 26.527.31326 broken
Until today (June 5, 26.602.40724) still broken

mike123789-dev · 1 month ago

same im sure it worked before but in latesest version 26.527.60818(3437 it doesnt work

pssuryaprakash1-creator · 1 month ago

+1,

Jules-Astier · 1 month ago

I can reproduce this on a newer Codex Desktop build with a minimal @modelcontextprotocol/ext-apps stdio server.

Environment:

Codex Desktop: 26.609.30741 (bundle build 3808)
Bundled Codex CLI/runtime: codex-cli 0.140.0-alpha.2
macOS arm64
MCP server: local stdio server
Feature flags:
features.apps = true
features.enable_mcp_apps = true

The MCP tool descriptor advertises all three resource URI forms that Codex core recognizes:

{
  "ui": {
    "resourceUri": "ui://codex-iframe-repro/hello.html",
    "prefersBorder": true
  },
  "ui/resourceUri": "ui://codex-iframe-repro/hello.html",
  "openai/outputTemplate": "ui://codex-iframe-repro/hello.html",
  "openai/resultCanProduceWidget": true,
  "openai/widgetAccessible": true
}

The tool call result also includes matching metadata:

{
  "structuredContent": {
    "title": "Codex MCP iframe repro",
    "message": "Visible iframe?",
    "accent": "rose",
    "resourceUri": "ui://codex-iframe-repro/hello.html"
  },
  "_meta": {
    "ui": {
      "resourceUri": "ui://codex-iframe-repro/hello.html"
    },
    "ui/resourceUri": "ui://codex-iframe-repro/hello.html",
    "ui.resourceUri": "ui://codex-iframe-repro/hello.html",
    "openai/outputTemplate": "ui://codex-iframe-repro/hello.html",
    "openai/resultCanProduceWidget": true,
    "openai/widgetAccessible": true,
    "mcp_app_resource_uri": "ui://codex-iframe-repro/hello.html"
  }
}

The raw Codex session event confirms that Codex core extracted the MCP App resource URI from the tool metadata:

mcp_tool_call_end
server: codex_iframe_repro
tool: show_codex_iframe_repro
mcp_app_resource_uri: ui://codex-iframe-repro/hello.html

But the Desktop UI still only rendered the textual URI:

ui://codex-iframe-repro/hello.html

I did not observe any resources/read event in the session, and the inline iframe was not rendered.

So this still appears broken in 26.609.30741: custom MCP Apps are detected at the core/tool-call level, but the Desktop renderer/resource hydration path does not fetch/render the declared text/html;profile=mcp-app resource.

I also checked PR #19884. It only documents/implements the enable_mcp_apps under-development feature flag and schema entry; I did not find another documented local enablement flag beyond setting features.enable_mcp_apps = true or running:

codex features enable enable_mcp_apps

vozer · 1 month ago

Same, can reproduce and activating Feature Flag did not help

vozer · 1 month ago

Implemented a clean prototype for this in my fork.

What changed:

completed MCP tool-call items now carry mcpAppResourceContents
Codex hydrates the MCP app resource server-side after a successful tool call when enable_mcp_apps is enabled
failed hydration logs a warning and does not change the tool-call result
regression coverage was added for inline MCP app resource hydration

https://github.com/vozer/codex/commit/03b480d5abf89fa954b97941d57540b6976123cf

0xdevalias · 29 days ago