[BUG] Desktop: MCP widgets have no working export path — "Copy to clipboard" fails with cloud-only advice, "Download file" silently no-ops

Summary

In the Claude Code desktop app, neither export action on an MCP Apps widget works:

1. Copy to clipboard → fails with the toast: Copy failed — try from claude.ai in browser
2. Download file → nothing happens at all. No file, no error, no toast.

Together these leave widget content with no way out of the UI. That matters because widgets are frequently used for summaries and recaps that are meant to be pasted somewhere else.

Why the error message is actively wrong

The copy failure advises the user to "try from claude.ai in browser." For a local (non-cloud) session this is impossible to follow — local sessions never sync to claude.ai, so the suggested destination does not contain the thread. The message appears to be a hardcoded fallback written for the web app that also fires in desktop, where the advice cannot apply.

If the copy path genuinely cannot work in desktop, the message should say so and point at the download path instead — except the download path is also broken (see above).

Likely cause

Consistent with the widget iframe being sandboxed without the permissions both actions need:

• navigator.clipboard.writeText() requires delegated clipboard-write permission plus a focused document; without it the promise rejects and the catch block shows the canned string.
• A download initiated inside an iframe whose sandbox attribute lacks allow-downloads is blocked silently — which matches "nothing happens" exactly, including the absence of any error.

Not verified against source; offered as the hypothesis that fits both symptoms.

Environment

| | |
|---|---|
| App | Claude Code desktop (entrypoint=claude-desktop) |
| Version | 2.1.255 (session began on 2.1.247 — an update landed mid-session) |
| CLI version | 2.1.229 |
| OS | Windows 11 Pro 10.0.26200 |
| Session type | Local, not cloud-backed |
| Widget source | mcp__visualize__show_widget |

Possibly relevant to when this started: the app updated from 2.1.247 to 2.1.255 during the affected session.

Steps to reproduce

1. In the Claude Code desktop app, run a tool that renders an MCP Apps widget (e.g. mcp__visualize__show_widget).
2. Open the widget's … overflow menu.
3. Click Copy to clipboard → toast reads Copy failed — try from claude.ai in browser.
4. Click Download file → nothing happens.

Expected

Either action should get the widget's content out of the UI. Failing that, the error text should describe a route the user can actually take on the platform they are on.

Actual

Both export paths fail; one fails with instructions that are impossible to follow in a local session, the other fails with no feedback whatsoever.

Impact / workaround

The only recovery I found was reading the widget payload back out of the session transcript at
~/.claude/projects/<project>/<session-id>.jsonl — each show_widget call stores its full widget_code in the tool_use block, so the content is recoverable by parsing the JSONL and converting the HTML. That works, but it is not a reasonable ask of a normal user.

Suggested fixes

1. Add allow-downloads to the widget iframe sandbox so Download file works — this alone restores a viable export path.
2. Delegate clipboard-write to the widget frame, or fall back to a document.execCommand('copy') / hidden-textarea path when the async Clipboard API is unavailable.
3. Replace the hardcoded "try from claude.ai in browser" string with platform-aware text; never suggest claude.ai for a local session.
4. Surface a visible error when a download is blocked, rather than failing silently.

Related (not duplicates)

• #90594 — mcp__visualize__show_widget returns persistent 404
• #88370 — MCP Apps widgets stopped rendering after 2.1.234 rollout
• #90040 — desktop: collapsed MCP widgets re-expand on their own

Searched open issues for widget copy clipboard, show_widget download, visualize widget clipboard, and the literal error string — no existing report of this.