MCP App sandbox omits allow-same-origin, so apps and their embeds run with a null origin #4271

Short summary

MCP App views render in an <iframe> with sandbox="allow-scripts allow-popups allow-forms". Because allow-same-origin is missing, every MCP App, and every frame it embeds, runs with an opaque null origin. Browser storage throws, and cross-origin requests send Origin: null, which origin-checking services reject. The MCP Apps spec requires the sandbox to have allow-scripts and allow-same-origin.

Affected version or release

1.1.23 (Windows)

Installation context

Windows 11 Enterprise 25H2 (build 26200.9448), WebView2 Runtime 154.0.4258.37, desktop installation. Local session with a custom MCP server that exposes an MCP App resource (text/html;profile=mcp-app), shown as an inline MCP App view.

What happened?

• The MCP App <iframe> loads from http://mcp-app-guest.localhost/<token> with sandbox="allow-scripts allow-popups allow-forms".
• Inside the app, window.origin is "null" and localStorage throws:
  SecurityError: Failed to read the 'localStorage' property from 'Window': The document is sandboxed and lacks the 'allow-same-origin' flag.
• Sandbox flags are inherited, so a cross-origin page the app embeds (allowed via _meta.ui.csp.frameDomains) is also opaque, even if its own <iframe> includes allow-same-origin. Its API calls send Origin: null. In our case, the embedded service rejects the CORS preflight with HTTP 400 and the embed never renders.
• App authors can't work around this. The flags are set on the host's <iframe>, a frame can't relax its parent's sandbox, and MCP Apps resource metadata has no field for sandbox flags.

As a local check, adding allow-same-origin to the MCP App <iframe> at runtime through DevTools (only for mcp-app-guest.localhost frames, no other change) makes the same app and its embed load and render normally. The same app also works in a host that uses the MCP Apps reference host's sandbox (allow-scripts allow-same-origin allow-forms).

Steps to reproduce

1. Start the Copilot app with WebView2 DevTools enabled. For example, set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--remote-debugging-port=9223 before launching, then open edge://inspect.
2. Call any tool that renders an MCP App.
3. Inspect the MCP App <iframe>. Its sandbox is allow-scripts allow-popups allow-forms.
4. In the console, switch to the MCP App frame and run window.origin (returns "null") and localStorage.length (throws SecurityError).

Or add this probe to any MCP App's HTML:

<pre id="probe"></pre>
<script>
  const lines = [`window.origin: ${window.origin}`];
  try { localStorage.setItem('probe', '1'); lines.push('localStorage: ok'); }
  catch (e) { lines.push(`localStorage: ${e.name}`); }
  document.getElementById('probe').textContent = lines.join('\n');
</script>

In Copilot it prints window.origin: null and localStorage: SecurityError.

Expected behavior

MCP App views get a real, non-opaque origin, as the MCP Apps spec requires (2026-01-26, Sandbox proxy):

1. The Host and the Sandbox MUST have different origins.
2. The Sandbox MUST have the following permissions: allow-scripts, allow-same-origin.

The reference host uses allow-scripts allow-same-origin allow-forms (basic-host sandbox.ts), and the proposed conformance tests assert a non-opaque app origin (modelcontextprotocol/ext-apps#743).

Copilot already meets the first rule: apps load from mcp-app-guest.localhost, not the app shell's origin. It also honors _meta.ui.csp.frameDomains by adding those origins to the app's frame-src, so embedding cross-origin pages is supported. But those pages inherit the opaque origin, so embeds that call their own APIs or use storage fail.

Additional context

Likely cause: This looks like a deliberate isolation choice rather than an oversight. Every MCP App loads from the same origin (mcp-app-guest.localhost), so adding allow-same-origin alone would let apps from different servers share storage and script each other's frames. Leaving it out prevents that, but breaks spec conformance and any app that needs a real origin.

Suggested fix: Give each MCP server (or each app) its own origin, for example <server-id>.mcp-app-guest.localhost, then add allow-same-origin. See the discussion on unique sandbox origins in modelcontextprotocol/ext-apps#213.

Who is affected: Self-contained apps that only render tool data work today. Apps that use browser storage, call origin-checked or cookie-based APIs, or embed authenticated third-party content fail. The MCP Apps docs recommend localStorage for view-state persistence (patterns), which fails in Copilot.

Possibly related: #781 (MCP app canvas does not render), unverified.

Logs: Debug logs aren't attached because they include details of a private MCP server. The behavior reproduces with any MCP App using the steps above. I can share sanitized logs if needed.