Repository navigation
Sandbox origin-based state #213
Description
Current test environments often use a static sandbox origin which might create assumptions around localStorage and other origin-based forms of state.
Should the spec make some kind of statement on persistence and/or state leaks between different apps?
Activity
idosal commentedon Jan 22, 2026
Thanks @hybrist ! There's a section dedicated to the sandbox which explicitly states they MUST have different origins. Do you think there's anything to clarify further?
hybrist commentedon Jan 22, 2026
Afaik it only says different but not unique which is where my question comes in ("The Host and the Sandbox MUST have different origins.").
What I'm concerned about is people testing their apps with a static sandbox origin like
mcp-sandbox.localhost:5200but then in prod each instance of their MCP app gets a unique sandbox origin (unique-random-id-h4sH.sandbox.host.com) and suddenly their code breaks because they stored something in local storage or were otherwise reliant on origin-based state/storage on the sandbox origin.idosal commentedon Jan 22, 2026
Oh, thanks for the clarification. I thought you were referring to UI<>Host leaks.
You're right, that may be confusing. WDYT about a callout that Hosts MAY use arbitrary origins and therefore the UI SHOULD NOT assume anything unless it defines the
domain_meta?hybrist commentedon Jan 22, 2026
My personal preference would be a stronger stance of "hosts MUST use unique origins" or at least "host SHOULD use unique origins". Implying that it's okay for some hosts to use shared origins across multiple MCP apps seems like an interop and even worse privacy/security concern. Making non-unique origins very explicit as an exception case would be much preferable I think.
Are there concerns with having a blanket "MUST be unique sandbox origin" as a starting point? Even in local development that should be possible via localhost subdomains.
idosal commentedon Jan 27, 2026
There are two concerns -
domain)They're both important. The second is definitely something the spec should address. The minimum requirement would be to mandate a unique origin per view. I imagine different hosts may prefer different levels of granularity (e.g., static, one per chat, unique per view instance, etc.). I'll open a proposal tomorrow, and we can iterate over it.
Thanks for bringing this up!
idosal commentedon Jan 28, 2026
@hybrist added to tomorrow's WG meeting (8 AM PST) to gather feedback from hosts. Please feel free to chime in.