Issue Station
Sign In
Tools hereToolbox

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

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46238•Fetched 2026-04-11 06:25:20
View on GitHub
Comments
1
Participants
2
Timeline
11
Reactions
0
Author
tocartetocarte
Participants
github-actions[bot]github-actions[bot]tocartetocarte
Timeline (top)
labeled ×5cross-referenced ×4closed ×1commented ×1

Error Message

| Test | Result | Error |

Root Cause

  • No AI platform currently supports inline video playback. This would be a first.
  • Unlocks an entire plugin category: video, audio, podcasts, live streams, music.
  • Related requests: #22903 (real-time visual pipes), #12676 (native video file support), #29602 (sandbox network allowlist).

Fix Action

Fix / Workaround

Current Workaround

Current workaround is handing the HLS stream URL to the OS via vlc:// protocol or direct link, which opens playback in VLC or the default browser. Functional but defeats the purpose of inline playback within Cowork.

RAW_BUFFERClick to expand / collapse

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

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

TestResultError
MP4 <video src="...">BlockedMedia load rejected by URL safety check
fetch() to public HTTPSBlockedFailed to fetch
HLS.js via CORS proxyBlockedmanifestLoadError (HTTP 0)
fetch() to localhostBlockedFailed to fetch
<iframe src="http://localhost:...">BlockedNo request received
Cloudflare tunnel (public HTTPS)BlockedFailed to fetch

Note: <script src="https://cdnjs.cloudflare.com/..."> loads fine — HLS.js initializes. But all runtime network access is blocked (fetch, XHR, video src, audio src, WebSocket).

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.
  • Related requests: #22903 (real-time visual pipes), #12676 (native video file support), #29602 (sandbox network allowlist).

Proposed Solution

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.

Current Workaround

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

Alternative Solutions

Current workaround is handing the HLS stream URL to the OS via vlc:// protocol or direct link, which opens playback in VLC or the default browser. Functional but defeats the purpose of inline playback within Cowork.

Priority

High - Significant impact on productivity

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 branded channel grid
  4. User clicks a channel → video plays inline in the artifact
  5. User asks "What else is on?" → Claude updates the artifact with new channels

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.

Related issues: #22903, #12676, #29602

extent analysis

TL;DR

Implementing an allowlisted domains feature for plugins or relaxing sandbox restrictions for media elements could resolve the issue of blocked outbound network access in sandboxed iframes.

Guidance

  • Investigate the proposed solutions, focusing on allowlisted domains per plugin or relaxed sandbox for media elements only, as these seem to directly address the issue.
  • Consider the security implications of each proposed solution to ensure that any changes do not introduce vulnerabilities.
  • Evaluate the native media artifact type proposal as a potential long-term solution that could provide a more integrated and secure way to handle media playback.
  • Review related issues (#22903, #12676, #29602) to understand the broader context and potential synergies with other features.

Example

No specific code example is provided due to the lack of direct code references in the issue. However, any solution would likely involve modifying the sandboxing logic to permit specified media origins or implementing a new media artifact type.

Notes

The choice of solution will depend on the specific requirements and constraints of the Cowork platform, including security considerations and the need to support a wide range of media types and plugins.

Recommendation

Apply a workaround such as allowlisted domains per plugin as an interim solution, as it seems to offer a balanced approach between security and functionality, allowing for the declaration of permitted media origins on a per-plugin basis.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#memory management#API rate limit#retriever error#indexing error#inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING