[MCP Apps] Nested MCP calls inside functions.exec do not create renderable widget items

Summary

Codex Desktop successfully calls an MCP App tool and receives valid widget metadata, structured content, and HTML. However, when the MCP call is nested inside functions.exec, the thread records only the outer custom tool call.

The nested MCP result does not become a top-level McpToolCall thread item, so the widget renderer has nothing to mount. The result is serialized as text instead of being displayed as an interactive MCP App card.

This was reproduced with the OpenAI-curated Apple Music connector.

Environment

• Codex Desktop: 26.727.51351 (build 6119)
• Bundled Codex CLI: 0.146.0-alpha.9.2
• Platform: macOS, Apple Silicon
• Connector: Apple Music

No account identifiers, thread identifiers, local paths, playlist contents, or raw logs are included in this report.

Steps to reproduce

1. Open a Codex Desktop task.
2. Invoke the Apple Music App and ask it to generate a playlist.
3. Codex calls apple_music_get_track_details_batch through functions.exec.
4. The Apple Music request succeeds and returns matched catalog tracks.
5. Observe that no Apple Music card is rendered in the conversation.

Actual behavior

The MCP App call succeeds:

• structuredContent contains body and status.
• Tool-result _meta contains appleweb/html.
• The result contains a createPlaylistAction.
• The widget descriptor contains both _meta.ui.resourceUri and _meta["openai/outputTemplate"].
• mcpServer/resource/read succeeds for the referenced widget resource.

However:

• The rollout contains a top-level custom_tool_call for functions.exec.
• The Apple Music request appears only as a nested mcp_tool_call_end event.
• No top-level McpToolCall / ThreadItem::McpToolCall is created.
• No widget renderer or widget-data initialization event follows.
• The HTML/result envelope is surfaced as ordinary text.
• No interactive card appears.

Sanitized event shape:

custom_tool_call
  name: exec
  └── nested mcp_tool_call_end
        server: codex_apps
        tool: apple_music_get_track_details_batch
        result: Ok
        structuredContent: [body, status]
        _meta: [appleweb/html]

There is no corresponding top-level event shaped like:

McpToolCall
  appContext.resourceUri: ui://widget/get-track-details-batch.html

Expected behavior

A successful nested MCP App result should either:

1. Be promoted to a renderable top-level MCP tool-call item carrying the App resource context; or
2. Have its complete MCP result envelope forwarded through functions.exec to the widget renderer.

The forwarded data should preserve at least:

• content
• structuredContent
• top-level _meta
• ui.resourceUri
• openai/outputTemplate
• App/widget context and action-bridge identifiers
• tool ID and call ID

The Apple Music widget should then render as an interactive card.

Why this appears to be a Codex transport issue

The connector and resource both appear healthy:

• The catalog call succeeds.
• The widget descriptor is present.
• The widget HTML resource can be read successfully.

The failure occurs after the nested MCP result is returned but before Codex creates the UI/thread item required by the renderer.

Retrying the operation does not change this event shape.

Related issues

• #33717 — Deferred MCP tool calls drop structuredContent / _meta
• #21019 — Codex Desktop does not render MCP Apps inline UI resources
• #29210 — Canva MCP App succeeds but returns no HTML preview

This may share the result-envelope loss described in #33717, but this reproduction differs because no usable card is mounted at all: the nested MCP call never becomes a top-level renderable thread item.

Suggested fix

Preserve nested MCP App results as first-class MCP call records instead of flattening them into the outer functions.exec text result.

Alternatively, add explicit support in the Codex client for forwarding nested MCP App result envelopes into the widget-rendering pipeline.