claude-code - 💡(How to fix) Fix [ENHANCEMENT] Enable media playback in Cowork artifact sandbox (video/audio/HLS) [1 participants]

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

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: #22903 (real-time visual pipes), #12676 (native video file support), #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).