Skip to content

fix(mcp-apps): authorize wss:// for app connect domains - #7765

Merged
viktormarinho merged 1 commit into
mainfrom
cecilia-marques/weekstarts-in-studio
Oct 7, 2026
Merged

viktormarinho merged 1 commit into
mainfrom
cecilia-marques/weekstarts-in-studio

Conversation

@cecilia-marques

@cecilia-marques cecilia-marques commented Oct 7, 2026 •

Copy link
Copy Markdown
Collaborator

What

MCP apps declare allowed connect origins via the UI resource's
_meta.ui.csp.connectDomains, which the CSP injector emits as connect-src.
But an app that lists https://host still can't open a WebSocket to it:
connect-src https://host does not authorize wss://host — CSP does not
derive the WebSocket scheme from an https: source. Apps can't work around it
(validateDomains only accepts http(s)://).

This injector now also emits each connect domain's WebSocket-scheme equivalent
(https://host → wss://host, http://host → ws://host), originals first so
plain fetch/XHR matching and the existing output prefix are unchanged.

Why

Unblocks realtime (Yjs/WebSocket) co-editing in MCP apps. Concretely: the
rituals app (weekstarts/weekends) ships live co-editing via a Cloudflare
Durable Object relay; its iframe currently gets connect-src https://rituals.deco-cx.workers.dev and the WebSocket is silently blocked, so it
falls back to non-live saves.

Evidence

Reproduced in the deployed Studio iframe condition (sandboxed iframe + injected
CSP), hitting the real relay:

CSP connect-src WebSocket result
https://rituals.deco-cx.workers.dev blocked (error, no open)
wss://rituals.deco-cx.workers.dev opens + syncs
https://… wss://… (this fix) opens + syncs

The same socket connects fine from the top document, confirming it's the
iframe's connect-src scheme, not the relay.

Scope / risk

Additive and backward-compatible: it only widens connect-src to the
WebSocket scheme of domains an app already declared. Existing csp-injector
tests pass; added one asserting the wss/ws entries.

🤖 Generated with Claude Code


Summary by cubic

MCP apps that declare https:// connect domains could not open WebSockets to those hosts, because CSP does not derive wss: from an https: source. The injector now also emits each connect domain's WebSocket-scheme equivalent (https://host → wss://host, http://host → ws://host), originals first. This unblocks realtime co-editing in MCP apps while leaving existing connect-src output unchanged for fetch/XHR.

Written for commit 3405a15. Summary will update on new commits.

Review in cubic Turn on auto-fix

An MCP app that declares an https connect domain (resource `_meta.ui.csp.
connectDomains`) still can't open a WebSocket to it: the injected
`connect-src https://host` does NOT authorize `wss://host` — CSP does not derive
the WebSocket scheme from an https: source (verified in Chrome: the socket is
blocked inside the sandboxed iframe, while identical from the top document it
connects). Apps can't work around it — validateDomains only accepts http(s).

The injector now adds each connect domain's WebSocket-scheme equivalent
(https→wss, http→ws), originals first so fetch/XHR matching and existing output
are unchanged. This unblocks realtime (Yjs) co-editing in MCP apps.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
@github-actions github-actions Bot added the claude PR authored by a coding agent label Oct 7, 2026
@viktormarinho
viktormarinho merged commit 1717a06 into main Oct 7, 2026
34 checks passed
@viktormarinho
viktormarinho deleted the cecilia-marques/weekstarts-in-studio branch October 7, 2026 02:27
decocms Bot pushed a commit that referenced this pull request Oct 7, 2026
PR: #7765 fix(mcp-apps): authorize wss:// for app connect domains
Bump type: patch

- @decocms/shared (packages/shared/package.json): 0.136.0 -> 0.136.1

Deploy-Scope: both
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

claude PR authored by a coding agent

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants