Grok host: MCP Apps iframe rendering unstable for Paybox connector (custom BYO MCP)

[cursor]

Summary

Paybox (MoonPay) reports that Grok’s MCP Apps iframe host is extremely buggy when rendering Paybox’s in-chat UI widgets via a custom BYO MCP connector (https://mcp.paybox.sh or equivalent production endpoint).

The same Paybox MCP App UI resource renders on other major hosts (ChatGPT, Claude with correct handshake/CSP), but Grok’s iframe lifecycle is unreliable enough to block normal Paybox flows (signing, approvals, balance updates).

Reporter

MoonPay Paybox team (internal escalation from Paybox engineering)

Environment

• Host: Grok web (grok.com) — custom MCP connector (Bring Your Own MCP)
• MCP server: Paybox MCP (wallet / approvals / signing UI)
• UI: MCP Apps HTML resources (text/html;profile=mcp-app) served from Paybox iframe surfaces (app.paybox.sh)
• Protocol: MCP Apps / io.modelcontextprotocol/ui capability

Observed problems (high level)

Paybox engineers report Grok’s iframe support is extremely buggy compared to Claude and ChatGPT. Symptoms align with known MCP Apps host-integration failure modes:

1. Stale / non-updating UI — iframe continues showing prior state (e.g. pending approval button) after the underlying transaction completes; host does not deliver updated tool-result / lifecycle notifications reliably.
2. Signing window failures — signing / passkey approval surfaces fail to load or hang inside Grok’s embedded iframe.
3. Multiple concurrent iframes — duplicate widget instances for a single logical action (e.g. several signer-key regeneration iframes in one session), with poor cross-iframe state coordination.
4. General iframe lifecycle instability — intermittent blank/hidden widgets, missed ui/initialize / ui/notifications/initialized handshakes, or postMessage delivery gaps (similar symptoms documented for other hosts in ext-apps issues, but Grok-specific regressions appear worse / more frequent for Paybox).

Expected behavior

Per MCP Apps host requirements:

1. Host calls tools/call and receives structuredContent + UI linkage via _meta.ui.resourceUri
2. Host fetches HTML via resources/read and mounts sandboxed iframe
3. Host completes UI handshake and delivers tool-input / tool-result notifications
4. Widget updates reflect server state changes without requiring the user to ask the model to “verify” or open external approval links

Actual behavior

Grok intermittently fails steps 2–4. Users see broken, stale, or duplicated Paybox UI inside Grok chat while the same flows work on other MCP hosts.

References / related issues

• Cross-host MCP Apps rendering debugging: Bug Report: MCP Apps UI Resource Not Rendering in Claude Desktop / claude.ai #671
• Working minimal demo that renders on ChatGPT + Grok + Claude (when handshake fixed): https://github.com/primevalsoup/mcp-apps-claude-demo
• Paybox parallel report (Claude stale UI after successful swap): internal Paybox eng Slack 2026-08-19

Request for xAI / Grok host team

Please investigate Grok’s MCP Apps iframe host implementation for custom connectors:

• iframe mount + visibility (ui/initialize / ui/notifications/initialized)
• delivery of tool-result and lifecycle notifications after state changes
• handling multiple widgets in one conversation
• CSP / sandbox / postMessage bridge for third-party MCP App origins

Happy to provide repro videos, connector URL, and server logs on request.

[Booyaka101]

The spec-side half of this is testable locally now, which at least settles whether the Paybox resource is conformant while you wait on xAI.

I added three checks to mcp-app-debug that go after the symptoms in this report rather than mount time, which is all the existing ones covered. One drives a second tools/call with different arguments at the already-mounted app and watches for a second tool-result, so a widget that keeps showing a pending approval after the transaction lands fails it. One mounts the same view twice in a single page and fails if either bridge sees the other's postMessages. The third attempts window.open and a target=_blank click from inside the sandbox, which is as close as I can get to the signing-surface hang without a real passkey flow.

npx mcp-app-debug https://mcp.paybox.sh/mcp --profile spec --json

The caveat matters more than the feature, so up front: this does not emulate Grok. I have no way to test their host. The grok profile only varies the knobs this issue names (no tool-result redelivery, concurrent instances, popups blocked) and it cites this issue as its source, which is circular by construction. It reproduces the reported behaviour against your own app. It is not evidence about what Grok actually does.

Where it does help is the other direction. If the resource passes all ten checks under spec, that is a clean statement that the app is conformant and the divergence is host-side, with the raw postMessage frames to back it. --profile all --json emits a matrix plus per-check evidence that is shaped to paste into a thread like this one.

I ran it against primevalsoup/mcp-apps-claude-demo since it is referenced above. It fails two checks under spec, and both are artefacts of running a tunnel-shaped server on localhost rather than anything wrong with that demo: it computes ui.domain from https://<host>/mcp while I reached it over plain http, so the check reports a scheme-swap near miss, and its widget has no button to provoke an app-initiated tools/call.

MIT, source at https://github.com/Booyaka101/mcp-app-debug.