[ENHANCEMENT] Enable media playback in Cowork artifact sandbox (video/audio/HLS)

[tocarte]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Summary

Cowork artifacts block all outbound network access from the sandboxed iframe — including <video> elements, fetch(), XHR, and HLS.js streaming. This prevents any media-rich plugin from playing video or audio inline.

Test Results

Test	Result	Error
MP4 <video src="...">	Blocked	Media load rejected by URL safety check
fetch() to public HTTPS	Blocked	Failed to fetch
HLS.js via CORS proxy	Blocked	manifestLoadError (HTTP 0)
fetch() to localhost	Blocked	Failed to fetch
<iframe src="http://localhost:...">	Blocked	No request received
Cloudflare tunnel (public HTTPS)	Blocked	Failed to fetch
Bitmovin Player v8 (licensed) loading HLS	Blocked	SOURCE_COULD_NOT_LOAD_MANIFEST

Note: <script src="https://cdnjs.cloudflare.com/..."> loads fine — libraries like HLS.js and Bitmovin Player initialize. But all runtime network access is blocked (fetch, XHR, video src, audio src, WebSocket), so no stream ever loads.

Why This Matters

• No AI platform currently supports inline video playback. This would be a first.
• Unlocks an entire plugin category: video, audio, podcasts, live streams, music.
• Industry pattern confirmed this week: Bitmovin (leading video player vendor) publicly demoed a "Bitmovin Player MCP" April 14-15 with the same goal — inline playback in Claude and ChatGPT. We are a Bitmovin Player customer and reproduced their setup with our license on a clean Cowork artifact; we hit the identical sandbox restrictions. The same blocker affects both Bitmovin's demo and our production plugin. This isn't vendor-specific.
• Developers are already bypassing this unofficially. The "Claude Artifacts Unlocker" Chrome extension exists on the Chrome Web Store specifically to disable CSP in Claude artifacts. A scoped, per-plugin allowlist would be strictly better than users globally disabling CSP via browser extensions — and would remove the incentive for that entire class of extension.
• Related requests: [FEATURE] Bidirectional Visual Streaming - Real-time Screen Share via CLI Pipes #22903 (real-time visual pipes), [FEATURE] Video Input Support in Claude Code #12676 (native video file support), Sandbox additionalAllowedHosts does not apply to network requests #29602 (sandbox network allowlist).

Proposed Solution

Proposed Solutions

Any of these would solve it:

1. Allowlisted domains per plugin — Plugins declare permitted media origins in their manifest (e.g., allowedMediaOrigins: ["*.akamaized.net"]). The sandbox permits <video>/<audio> to those domains only. Scoped, auditable, opt-in.

2. Native media artifact type — A first-class video/audio component in the artifact system, like HTML/React artifacts today. The platform handles playback securely outside the sandbox.

3. Relaxed sandbox for media elements only — Allow <video> and <audio> to load external sources while keeping fetch()/XHR restricted. Media elements consume content rather than exfiltrate data, making them lower risk.

Alternative Solutions

Current Workaround

Hand the stream URL to the OS (opens in VLC or default browser). Works, but defeats the purpose of inline playback in Cowork.

Priority

Critical - Blocking my work

Feature Category

MCP server integration

Use Case Example

1. User asks Claude in Cowork: "Show me live news channels"
2. MCP plugin returns channel data (name, logo, HLS stream URL)
3. Claude generates an HTML artifact with a channel grid
4. User clicks a channel - video plays inline in the artifact
5. User asks "What else is on?" - Claude updates the artifact

Step 4 currently fails because the artifact sandbox blocks the video element from loading the HLS stream. Every other step works today.

Additional Context

Tested on Cowork (Claude Desktop, macOS), April 2026. HTML artifacts only — React artifacts can't load CDN scripts like HLS.js.

This blocker was also reproduced with a licensed Bitmovin Player v8 setup (Bitmovin publicly demoed a "Bitmovin Player MCP" the week of April 14-15, 2026). Same result: SOURCE_COULD_NOT_LOAD_MANIFEST — library loaded, license validated, every stream source blocked by sandbox network policy.

Related issues: #22903 (real-time visual pipes), #12676 (native video file support), #29602 (sandbox network allowlist).

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.