v2: file preview of PDF/HTML shows "This content is blocked" (CSP missing blob: in frame-src/object-src) #54312

Summary

In the opencode v2 web/desktop UI, previewing a .pdf or .html file from the file tree shows the browser block page "已阻止此内容。请与网站所有者联系以解决此问题。" ("This content is blocked. Contact the site owner to fix the issue.") instead of the file. The file itself is fine — the same file opens normally in an external viewer/browser. The cause is the server's Content-Security-Policy, which governs frame-src/object-src via default-src 'self' and does not allow blob: for frames/objects, while the preview renders those files from a blob: URL.

Environment

• opencode version: 2.0.26 (V2; npm package @opencode/[email protected], isolated prefix)
• OS: Linux 6.18.40.1-microsoft-standard-WSL2 (WSL2), x86_64; Windows 11 host
• Terminal: Unavailable: not applicable — reported in the web UI (server opencode serve --hostname 0.0.0.0 --port 4098)
• Shell: /bin/bash
• Install/channel: release/latest, installed via npm into an isolated prefix (/opt/opencode-v2)
• Active plugins: none declared in the V2 config (/var/lib/opencode-v2/config/opencode/opencode.jsonc has no plugin/mcp keys)

Reproduction

1. Start the v2 server: opencode serve --hostname 0.0.0.0 --port 4098.
2. Open the web UI (e.g. http://127.0.0.1:4098/) and open a workspace with a .pdf and an .html file (any valid file works).
3. In the file tree, open/preview the .pdf (and separately the .html).

Expected Behavior

The preview renders the PDF / HTML content inline.

Actual Behavior

The preview area shows the browser block page: "已阻止此内容。请与网站所有者联系以解决此问题。" Other types (.md, .txt, code, images, .csv) preview fine. The same PDF/HTML opens fine in an external browser/viewer, so the files are valid and only the in-app preview is affected.

Additional Context

Every response from the v2 server carries this CSP header (verified with curl -D- http://127.0.0.1:4098/):

content-security-policy: default-src 'self'; script-src 'self' 'wasm-unsafe-eval' 'sha256-...'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https: blob:; font-src 'self' data:; media-src 'self' data:; connect-src * data: blob:; worker-src 'self' blob:

Observations:

• There is no explicit frame-src or object-src, so both fall back to default-src 'self'.
• blob: is whitelisted only for img-src, connect-src, and worker-src — not for frame-src/object-src.
• PDF and HTML previews must use a framed/embedded element (<iframe>/<embed>/<object>), and the frontend builds a blob: URL from the file bytes (URL.createObjectURL(new Blob([...], { type: <mime> }))). Under default-src 'self', Chromium refuses to frame a blob: URL, producing the blocked-content page above.

Consistent with this: types that render as DOM (markdown/text/code) or via img-src (images, which do allow blob:) work; only PDF/HTML (frame/object) are blocked.

Suggested fix: add blob: (and likely data:) to the frame/object source policy, e.g. frame-src 'self' blob:; object-src 'self' blob: (or allow blob: in default-src).

Frequency: reproducible every time for .pdf and .html.