feat: enhance sandbox capability negotiation #158

idosal · 2025-12-15T22:45:35Z

Proposal to tackle #58 -

Add frameDomains and baseUriDomains overrides to Resource Metadata's ui/csp attribute
Add a permissions attribute(ui/permissions) to the Resource Metadata. Currently, it supports camera, microphone, and geolocation. There are many other permissions, but I think we should only add fields as they're needed. @alexi-openai could you please share what OpenAI allows?
Add csp to Host<>App capability negotiation (since it's non-trivial for the app to detect at runtime)

If it's acceptable, I'll add an E2E test before merging.

Thoughts?

pkg-pr-new · 2025-12-15T22:46:28Z

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/ext-apps@158

commit: e038020

Copilot

Pull request overview

This PR enhances the MCP Apps sandbox capability negotiation by adding support for additional CSP directives and permissions policies. The changes enable apps to request nested iframe support, custom base URI configuration, and browser permissions (camera, microphone, geolocation) through resource metadata.

Key changes:

Added frameDomains and baseUriDomains fields to CSP configuration for controlling nested iframes and base URI directives
Introduced permissions metadata for requesting camera, microphone, and geolocation access via Permission Policy
Extended host capability negotiation to include CSP support indicators (frameDomains and baseUriDomains)

Reviewed changes

Copilot reviewed 6 out of 9 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/types.ts	Added exports for new `McpUiResourcePermissions` type and schema
src/spec.types.ts	Defined new interfaces for permissions and extended CSP configuration with frame/baseUri domains
src/generated/schema.ts	Added Zod schemas for permissions and extended CSP schemas with new domain fields
src/generated/schema.test.ts	Updated type inference tests to include new permissions schema
src/generated/schema.json	Generated JSON schemas for new permissions and CSP extensions
specification/draft/apps.mdx	Documented new CSP fields and permissions with examples and security guidance
examples/simple-host/sandbox.html	Added new sandbox proxy HTML implementation (missing CSP/permissions handling)
examples/basic-host/src/sandbox.ts	Implemented CSP meta tag building and iframe allow attribute for permissions
examples/basic-host/src/implementation.ts	Extended resource data extraction to include new CSP and permissions metadata

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

specification/draft/apps.mdx

examples/basic-host/src/sandbox.ts

examples/simple-host/sandbox.html

examples/basic-host/src/sandbox.ts

Co-authored-by: Copilot <[email protected]>

ochafik

Thanks Ido!

ochafik · 2025-12-16T13:38:26Z

examples/basic-host/src/implementation.ts

+    baseUriDomains?: string[];
+  };
+  permissions?: {
+    camera?: boolean;


let's make these objects (as in capabilities) for future extensions?
e.g. what if one day there's fine-grained vers. coarse geolocation, or front vs. back camera permission, etc.

Like CSP, Permissions are coupled to the browser spec (Permissions Policy). I don't think we should diverge at this point. WDYT?

There are 40+ Permission Policies you can stuff in an iFrame. Consider keeping permissions very simple and flexible, just have it be a string[].

Benefits:

Client can set all permission policies with a single string. Flexible for future extensions.

Enforcing this on the client side is simple. We just stuff the string into an iFrame's allow. This is safe because invalid strings are silently ignored.

Still easily parseable on the server side. Server developer only has to do permissions.contains("camera");.

Alternatively create some interface and have permission be an array of that interface if type safety and enforcement is of high importance.

interface Permissions { camera: "camera", .... }

permissions?: Permissions[]

examples/simple-host/sandbox.html

ochafik

We should tell app what permissions were granted (and potentially which domains were allowed)

…ties

matteo8p · 2025-12-22T22:43:11Z

Is there an iFrame in the ext-apps project, or that out of the scope of this extension project? I'm wondering where the permissions are getting enforced into the iFrame.

matteo8p · 2025-12-22T22:48:39Z

I can see this being useful if the MCP server needs to know what the browser capabilities / permissions are. However, I'm pretty sure you can also fetch the browser capability within the widget too using document.featurePolicy.allowedFeatures().

https://developer.mozilla.org/en-US/docs/Web/API/FeaturePolicy/allowedFeatures

I perhaps React widgets should be using this instead as a source of truth.

matteo8p · 2025-12-22T23:01:32Z

@idosal I think OpenAI currently allows local-network-access *; microphone *; midi *

I have no clue why midi is on there. That's for music instruments haha

idosal · 2026-01-07T00:30:28Z

I can see this being useful if the MCP server needs to know what the browser capabilities / permissions are. However, I'm pretty sure you can also fetch the browser capability within the widget too using document.featurePolicy.allowedFeatures().

https://developer.mozilla.org/en-US/docs/Web/API/FeaturePolicy/allowedFeatures

I perhaps React widgets should be using this instead as a source of truth.

Thanks @matteo8p ! Permissions were originally excluded from negotiation because they could be detected directly. It was considered that the negotiation assumes less about the app runtime and the developer's awareness of the browser APIs. We should explore this further with the community to come to a decision.

ochafik · 2026-01-07T16:14:34Z

examples/simple-host/sandbox.html

+          if (event.data && event.data.method === 'ui/notifications/sandbox-resource-ready') {
+            const { html, sandbox, permissions } = event.data.params || {};
+            // Note: csp is not extracted here - CSP is set via HTTP response headers in serve.ts
+            if (typeof sandbox === 'string') {


we probably need to set the sandbox attribute in the host itself (and let them be inherited transparently here), cf. comments from @domfarolino during today's meeting.

(or else, the child, being same origin, will be able to change its own sandbox attributes by poking at its parent dom ; or would be able to create other iframes w/o these limitations)

(same way that CSP settings are defined in the headers serving this page, and not injected by this page)

Yeah, I think whatever features are enabled inside of sandbox.html will be inherited by the same-origin iframe inner. So I think what really needs to happen is the explicit capability delegation to the iframe whose source is sandbox.html, and we should get delegation to the same-origin app contents for free. This is important because any changes made to sandbox and permissions policies here, after inner has been inserted into the DOM, will not apply to content (the html string, in this case) that has been synchronously written into the frame after the attributes change. For those attributes to take effect, the inner iframe will have to re-navigate to apply the attribute changes.

domfarolino · 2026-01-07T17:07:09Z

examples/simple-host/sandbox.html

+          if (event.data && event.data.method === 'ui/notifications/sandbox-resource-ready') {
+            const { html, sandbox, permissions } = event.data.params || {};
+            // Note: csp is not extracted here - CSP is set via HTTP response headers in serve.ts
+            if (typeof sandbox === 'string') {


Yeah, I think whatever features are enabled inside of sandbox.html will be inherited by the same-origin iframe inner. So I think what really needs to happen is the explicit capability delegation to the iframe whose source is sandbox.html, and we should get delegation to the same-origin app contents for free. This is important because any changes made to sandbox and permissions policies here, after inner has been inserted into the DOM, will not apply to content (the html string, in this case) that has been synchronously written into the frame after the attributes change. For those attributes to take effect, the inner iframe will have to re-navigate to apply the attribute changes.

domfarolino · 2026-01-07T17:10:00Z

examples/simple-host/sandbox.html

+              try {
+                if (inner.contentDocument) {
+                  inner.contentDocument.open();
+                  inner.contentDocument.write(html);


Note that as mentioned above, I don't think any changes made to inner's allow or sandbox attributes will take effect after inner has been inserted to the DOM. You'll need to re-navigate the iframe for those attributes to stick.

Probably what you want to do is hold of on appending inner to the DOM until after you parse and set the intended attribute values. Or, given the comment further above, maybe we don't need to send the attribute values all the way down here, since inner should inherit most things from sandbox.html, since it's a same-origin iframe.

Implements early support for proposed CSP extensions to the MCP Apps spec: - frameDomains: Controls frame-src directive for nested iframes - baseUriDomains: Controls base-uri directive This anticipates changes proposed in: modelcontextprotocol/ext-apps#158 Note: The upstream spec PR is not yet merged, but we're implementing early to validate the approach.

aharvard · 2026-01-08T15:25:16Z

Getting ahead of this and goose and implementing frameDomains and baseUriDoamins: block/goose#6399

PTAL if interested.

feat: enhance sandbox capability negotiation

699549e

idosal requested review from alexi-openai, antonpk1, Copilot, liady and ochafik December 15, 2025 22:45

Copilot started reviewing on behalf of idosal December 15, 2025 22:45 View session

Copilot AI reviewed Dec 15, 2025

View reviewed changes

specification/draft/apps.mdx Outdated Show resolved Hide resolved

examples/basic-host/src/sandbox.ts Show resolved Hide resolved

examples/simple-host/sandbox.html Outdated Show resolved Hide resolved

examples/basic-host/src/sandbox.ts Show resolved Hide resolved

Update specification/draft/apps.mdx

7aef0d8

Co-authored-by: Copilot <[email protected]>

ochafik requested changes Dec 16, 2025

View reviewed changes

ochafik reviewed Dec 17, 2025

View reviewed changes

idosal added 2 commits December 18, 2025 21:53

Merge remote-tracking branch 'origin/main' into feat/sandbox-capabili…

0e4e524

…ties

add all csp and permissions to host capabilities + update SEP

e038020

idosal requested a review from ochafik December 18, 2025 20:31

idosal mentioned this pull request Jan 7, 2026

Protocol discrepancies between MCP Apps and Apps SDK #201

Open

ochafik reviewed Jan 7, 2026

View reviewed changes

domfarolino reviewed Jan 7, 2026

View reviewed changes

aharvard mentioned this pull request Jan 8, 2026

Add frameDomains and baseUriDomains CSP support for MCP Apps block/goose#6399

Merged

feat: enhance sandbox capability negotiation #158

Are you sure you want to change the base?

feat: enhance sandbox capability negotiation #158

Conversation

idosal commented Dec 15, 2025

Uh oh!

pkg-pr-new bot commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ochafik left a comment

Choose a reason for hiding this comment

Uh oh!

ochafik Dec 16, 2025

Choose a reason for hiding this comment

Uh oh!

idosal Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

matteo8p Dec 22, 2025

Choose a reason for hiding this comment

Uh oh!

matteo8p Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ochafik left a comment

Choose a reason for hiding this comment

Uh oh!

matteo8p commented Dec 22, 2025

Uh oh!

matteo8p commented Dec 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

matteo8p commented Dec 22, 2025

Uh oh!

idosal commented Jan 7, 2026

Uh oh!

ochafik Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ochafik Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

domfarolino Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

domfarolino Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

domfarolino Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

aharvard commented Jan 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

pkg-pr-new bot commented Dec 15, 2025 •

edited

Loading

idosal Dec 18, 2025 •

edited

Loading

matteo8p Dec 22, 2025 •

edited

Loading

matteo8p commented Dec 22, 2025 •

edited

Loading

ochafik Jan 7, 2026 •

edited

Loading