fix(web): copy buttons in html_render visuals work#27462

Problem

A Copy button inside an html_render visual does nothing. The page's navigator.clipboard.writeText is rejected with NotAllowedError: … The Clipboard API has been blocked because of a permissions policy applied to the current document, because the sandboxed, opaque-origin iframe that shows the page has no Permissions Policy delegation for clipboard-write. Reproduced on main in the web client and in the Linux desktop app: a real Codex turn calls html_render with a <pre>echo hello-27402</pre> and a Copy button. Clicking Copy, inline or in the full-screen dialog, shows the error, and pasting gives back the old clipboard contents.

Change

allow="clipboard-write" on the two iframes that show html_render pages: HtmlRenderDocument (inline frame, full-screen dialog and the html_render attachment panel) and GuestHtmlRender (guest share page). Write only, no clipboard-read. The sandbox and opaque origin are unchanged. The browser still requires focus and a recent click inside the frame before the page can write.

This widens what agent-authored HTML may do. An html_render page can now write to the reader's clipboard when the reader clicks inside it, and that includes pages a guest sees on a share link. This is the same click-to-copy power any web page has. MCP apps, by contrast, get clipboard-write only when they declare it.

Scope and approval

Fixes pingdotgg/t3code#27402

Verification

• New browser test HtmlRenderDocument > lets the page copy to the clipboard when the reader clicks its button (apps/web/src/components/files/BrowserDocumentFrame.browser.test.tsx) clicks a Copy button inside the frame. It fails on main with the permissions-policy NotAllowedError and passes with the fix. The test grants clipboard-write to the Playwright context through two new browser commands, because headless Chromium otherwise denies the top frame too. The frame's permissions policy is still enforced.
• vp test run --project browser for BrowserDocumentFrame.browser.test.tsx and GuestPage.browser.test.tsx: 5/5 pass. vp run check:changed: format, lint, knip, typecheck, test and React compiler all pass.

Head b11311af8e differs from 1b1acc1bc9 only by a merge of main that does not touch the changed files, packages/shared/src/htmlRender.ts or the test setup.

Desktop (Electron, Linux): real app, no extra permissions

Electron 44.10.0 / Chromium 152, Ubuntu 24.04 under Xvfb, repo-built desktop app with its bundled server, fresh homes, a real Codex turn with byte-identical HTML on both sides. 1440×900, DPR 1, dark. Clipboard reset to CLIPBOARD-SENTINEL-27402 before each run. Before pastes the sentinel; after pastes exactly echo hello-27402.

Recordings: before-R1-R2.mp4 · after-R1-R2.mp4

What else changed: the error text becomes "copied", which makes the inline frame shorter and moves "done" up. The independent agent turns differ in duration ("Worked for 33s" vs "14s"). Diff0 also shows 11 faint anti-aliasing pixels that disappear at threshold 8. Full report and transcripts: desktop-evidence-final.md. Seed and driver scripts: all-seed-and-driver-scripts-final.tar.gz.

Web (Chromium 156)

Recorded at 1cf14a498f → 8f66a27e8d, before merging main. Main has since added an 8px gutter to html_render pages, so these frames sit a few px differently from the current head. A rebuild at 1b1acc1bc9 showed the same copy and paste result. 1440×900, dark. The top frame was granted clipboard-write in the headless context. Each row has a before and after recording, plus Before/After/Diff0/DiffT stills: evidence index · fixture matrix · proof audit

• R1 inline, real app: sheet, before / after
• R2 full-screen dialog, real app: dialog sheet, paste sheet, before / after
• Scripts for the rows above: seed-driver.mjs · capture-driver.mjs · open-panel-harness.js · guest-component-harness.js

Harness rows at the current head (Chromium 156)

Before 305a90dce4, after b11311af8e. Real published attachment with byte-identical HTML that includes main's 8px gutter. 1440×900 CSS px, dark, DPR 2. No extra clipboard grants. Full report: evidence-refresh.md

R3: html_render attachment panel (LABELLED HARNESS: panel store opened with the real attachment and htmlRender: true; no production producer of that flag is established). Recordings: before-R3.mp4 (idle 0.5s → Copy 2.8s → failure 3.2s → sentinel pasted 5.0s) · after-R3.mp4 (idle 0.5s → Copy 2.8s → copied 3.0s → code pasted 4.8s)

R4: GuestHtmlRender (COMPONENT HARNESS: the real component, with the owner asset URL in place of the guest route). Recordings: before-R4.mp4 (idle 0.5s → Copy 2.8s → failure 2.9s → sentinel pasted 4.9s) · after-R4.mp4 (idle 0.5s → Copy 2.8s → copied 2.9s → code pasted 4.9s)

What else changed: the failure text becomes "copied", so the frame gets shorter (R3 by 19 CSS px; R4 from 178 to 140 px, which moves the paste controls up 38 px), and the pasted text changes. Every other pixel is identical. Scripts: seed-driver.mjs · capture-driver.mjs · open-panel-harness.js · guest-component-harness.js · run-refresh.mjs · diff-driver.py

Not verified

• cannot-verify macos: the macOS desktop app, where the issue was reported. Linux Electron above runs the same renderer.
• The real redeemed-guest flow (guest route, session and CSP) needs T3 Connect, which was not available. Only the component harness above covers it.
• Mobile renders html_render pages in a separate WebView and is not changed here.

Model and harness: Claude Opus 5.5 (lead, red test, review B) and GPT-6.1 Sol (review A, proof audit, captures) in Claude Code and Codex, orchestrated through T3 Code.

🤖 Generated with Claude Code