FE-1543: Grant clipboard permissions to the Petrinaut iframe

[claude]

Requested by Chris Feijoo · Slack thread

🌟 What is the purpose of this PR?

Copy and paste do not work in the Petrinaut editor as embedded in the HASH app's Processes page.

Before: the editor's copy and paste run through the async clipboard API. The Processes page embeds the editor in an iframe sandboxed without allow-same-origin, so the frame has an opaque origin. clipboard-read and clipboard-write are permission-policy controlled features whose default allowlist an opaque origin cannot match, so both calls are refused. The editor swallows the rejections, so the user sees nothing happen and the console stays quiet.

After: the frame is granted both clipboard features with the * allowlist, which is the one allowlist value that reaches an opaque origin — self and src cannot match one. The sandbox attribute is untouched, so the frame keeps its opaque origin and its existing isolation.

This change is unverified in a real browser. Chromium cannot be installed in the build environment, so it needs manual confirmation that copy and paste actually work in the embedded editor.

🔗 Related links

• FE-1543 (internal)
• Slack thread (internal)

🚫 Blocked by

• Nothing

🔍 What does this change?

• Adds allow="clipboard-read *; clipboard-write *" to the Petrinaut iframe on the Processes page. One line; no other change.

Pre-Merge Checklist 🚀

🚢 Has this modified a publishable library?

This PR:

• does not modify any publishable blocks or libraries, or modifications do not need publishing

📜 Does this require a change to the docs?

The changes in this PR:

• are internal and do not require a docs change

🕸️ Does this require a change to the Turbo Graph?

The changes in this PR:

• do not affect the execution graph

⚠️ Known issues

• Copy is the likelier of the two to start working: Chrome auto-grants clipboard-write to a page in an active tab and in a secure context, so delegating the feature may be all that copy needs. Paste is less certain — clipboard-read needs a permission grant, and an opaque origin cannot hold a persisted one. Whether Chrome's ephemeral "Paste" prompt is offered to an opaque-origin frame is not something the documentation settles, and it could not be tested here.
• Firefox restricted readText() to extensions for years and now exposes it to web content behind a paste prompt, so its behaviour in a sandboxed frame also needs checking.
• Sub-net and component instances being dropped on copy is a separate gap, tracked in FE-1071.

🐾 Next steps

• If clipboard-read still fails because an opaque origin cannot hold a permission grant, the fallback is to drive copy and paste off the copy and paste DOM events instead. Those events carry their own clipboard data and need no permission policy.
• The editor's empty catch blocks around the clipboard calls should surface the failure rather than swallowing it.

🛡 What tests cover this?

• None. An iframe attribute has no meaningful unit test, and the behaviour it affects only exists in a real browser.

❓ How to test this?

1. Check out the branch and open a process on the Processes page.
2. Select one or more nodes, copy them, and paste.
3. Confirm both work, in Chrome and in Firefox.

📹 Demo

n/a

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hash	Ready	Preview	Aug 28, 2026 3:05pm

3 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
hashdotdesign-tokens	Ignored		Aug 28, 2026 3:05pm
petrinaut	Skipped		Aug 28, 2026 3:05pm
petrinaut-docs	Skipped		Aug 28, 2026 3:05pm

[cursor]

PR Summary

Low Risk
Single iframe attribute change scoped to the Petrinaut embed; sandbox isolation is unchanged, with only clipboard delegation added for the opaque-origin frame.

Overview
Copy/paste in the embedded Petrinaut editor was blocked because the sandboxed iframe runs with an opaque origin, so the async Clipboard API could not use clipboard-read / clipboard-write under the default permission policy.

This PR adds allow="clipboard-read *; clipboard-write *" on the Processes page Petrinaut iframe. The * allowlist is required for opaque-origin frames (self/src do not apply). The existing sandbox (no allow-same-origin) is unchanged, so isolation from the HASH parent origin is preserved.

Manual browser verification (Chrome/Firefox) is still needed; paste behavior may depend on how each engine grants clipboard-read to sandboxed frames.

^{Reviewed by Cursor Bugbot for commit c091e13. Bugbot is set up for automated code reviews on this repo. Configure here.}