Why ChatGPT MCP apps use a double iframe architecture
Frédéric Barthelet, CTO of Alpic, explains why ChatGPT renders MCP app views inside a nested double iframe — the only approach that survives a systematic elimination of every simpler alternative.
Score breakdown
The double iframe architecture is the direct result of ruling out every simpler sandboxing approach, meaning MCP app developers who understand the constraint can anticipate the strict domain-declaration requirement and avoid submission rejections.
- 01Frédéric Barthelet is CTO and co-founder of Alpic, an MCP hosting company.
- 02MCP app views are HTML documents (with JS and CSS) rendered inside iframes as the result of tool calls.
- 03Using `srcdoc` alone shares the parent origin, causing ChatGPT's CSP to block all third-party scripts.
Frédéric Barthelet, CTO and co-founder of Alpic, opens by framing MCP apps as a new surface area for businesses inside conversational agents like ChatGPT and Claude — combining discoverability (apps surfaced in a store and in relevant conversations) with interactive UI rendered as views triggered by tool calls. Views are simple HTML documents (with JS and CSS) advertised on the MCP tool list at the start of a conversation, then rendered inside an iframe when the corresponding tool call is made.
Inspecting ChatGPT's DOM during view rendering reveals an unexpected structure: an iframe nested inside another iframe.
Inspecting ChatGPT's DOM during view rendering reveals an unexpected structure: an iframe nested inside another iframe. Barthelet walks through why every simpler approach was ruled out. Using `srcdoc` alone shares the parent origin, so ChatGPT's Content Security Policy blocks all third-party scripts. Relaxing the CSP to allow those scripts lets any app read ChatGPT's localStorage and cookies — a serious security hole. Adding the `sandbox` attribute closes that hole but removes origin-indexed storage. Restoring storage by adding `allow-same-origin` to the sandbox reintroduces the classic sandbox escape vulnerability. The double iframe is what remains after eliminating all alternatives: the outer iframe loads a lightweight script from a controlled subdomain (a different subdomain per app, preventing cross-app storage collisions), and that script loads the actual app HTML via `srcdoc` into the inner frame — the same architecture Facebook originally shipped for its app marketplace.
The talk also covers a concrete build-time implication: every external domain contacted by a view must be explicitly declared in the MCP app's metadata, or the submission will be rejected. Barthelet demonstrates Skybridge's CSP inspector, which diffs declared domains against actual live network calls during development to catch undeclared dependencies before submission.
Key facts
- 01Frédéric Barthelet is CTO and co-founder of Alpic, an MCP hosting company.
- 02MCP app views are HTML documents (with JS and CSS) rendered inside iframes as the result of tool calls.
- 03Using `srcdoc` alone shares the parent origin, causing ChatGPT's CSP to block all third-party scripts.
- 04Relaxing the CSP to allow third-party scripts exposes ChatGPT's localStorage and cookies to app code.
- 05Adding `sandbox` removes origin-indexed storage; adding `allow-same-origin` to restore it creates a classic sandbox escape.
- 06The double iframe solution uses an outer iframe on a unique controlled subdomain per app, which loads the actual app HTML via `srcdoc` into an inner frame — a pattern Facebook first used for its app marketplace.
- 07Every external domain a view touches must be declared in MCP app metadata or the submission is rejected; Skybridge's CSP inspector diffs declared domains against live network calls to catch gaps.
Topics
Summary and scoring are generated automatically from the original article. We always link back to the publisher and never republish images or paywalled content. Last processed Jun 16, 2026 · 23:11 UTC. How this works →