Sandbox CSP "dropping unsafe CSP source" warning misstates the reason — the entry is not an origin, not unsafe #2064

Which client?

Web

The problem

approveCspSources in clients/web/src/utils/sandbox-csp.ts drops any entry in an app's _meta.ui.csp domain lists that doesn't match SAFE_CSP_SOURCE, logging:

[mcp-app sandbox] dropping unsafe CSP source: 'unsafe-eval'

The word "unsafe" states a security verdict the check does not actually make. SAFE_CSP_SOURCE screens each entry for injection safety only — whether the string can break out of the <meta content="..."> attribute or inject a second directive with ;. It deliberately does not bound how broad a grant is; the function's own doc comment says so, and resourceDomains: ["*"] passes the filter and yields script-src 'unsafe-inline' *.

So when a value is dropped, the real reason is almost always that it isn't an origin. The ext-apps contract defines these four fields as origin lists (spec.types.ts: "Origins for static resources… Wildcard subdomains supported"), and a CSP keyword token such as 'unsafe-eval', 'wasm-unsafe-eval' or 'strict-dynamic' is not an origin — there is no field in the spec for requesting one.

This is not hypothetical. In #2012 the message led the reporter to file the drop as a security regression and to propose widening the regex, and the ensuing discussion was about XSS risk rather than about the field's contract. A message naming the actual cause would have made it a five-minute exchange.

Solution you have in mind (optional)

Reword the warning to state the expectation rather than a verdict, e.g.:

[mcp-app sandbox] dropping CSP source (expected an origin such as https://example.com,
https://*.example.com, a scheme like data:, or *): 'unsafe-eval'

Two details worth getting right while touching this:

• The single word "unsafe" is the whole defect — keep the new wording free of any claim about the safety of the dropped value, since the check isn't measuring that.
• Consider naming the field the entry came from (connectDomains, resourceDomains, …). The loop in approveCspSources already has key in scope, and an app declaring several lists currently gets identical messages with no way to tell which list the bad entry was in.

Scope is the warning text (and its assertion in sandbox-csp.test.ts). SAFE_CSP_SOURCE itself is unchanged — see #2012 for why the regex is behaving as designed, and ext-apps#605 for the upstream work on letting apps request CSP keywords at all.

Alternatives or workarounds you have tried

No response

Already built it locally?

No response