fix(ui): make copy-to-clipboard buttons work in non-secure contexts

[joshdutcher]

Fixes #3529.

Thinking Path

• Paperclip orchestrates AI agents for zero-human companies, and that orchestration is driven from a React SPA served by a Node/Express process
• The UI has ~16 copy-to-clipboard icons scattered across it — Copy Agent ID, token rotation, invite snippets, workspace paths, document bodies, issue markdown, worktree names, copy-as-markdown on comments, code-block copies in chat transcripts, etc.
• Anyone self-hosting Paperclip and reaching it over plain HTTP from another machine on their network — LAN hostname, Tailscale MagicDNS, Wireguard/VPN/SSH tunnel — loses the browser's Clipboard API. A page is only a secure context when it's HTTPS or HTTP loopback (localhost/127.0.0.1); private-network reachability doesn't count, so navigator.clipboard is undefined on any of these setups.
• 14 of those copy sites call navigator.clipboard.writeText(...) directly with no fallback — the resulting synchronous TypeError either dies inside a silent try/catch or bubbles out of the onClick before any .then callback can run, so the user sees no feedback at all: clipboard unchanged, icon doesn't animate, no toast
• The execCommand fallback pattern has already been accepted into the codebase twice — fix: copy button fallback for non-secure contexts #2472 (26069682, plus iteration commits 55833078, b64607c2, 944a7244) inlined it into CopyText.tsx, and commit 1e4ccb2b ("Improve mobile comment copy button feedback") inlined it into CommentThread.tsx — but neither PR attempted consolidation, so the codebase now has two near-identical copies of the same textarea-+-execCommand dance and 14 other sites that never got the treatment
• This pull request consolidates both existing fallbacks into a single shared copyTextToClipboard utility at ui/src/lib/clipboard.ts and migrates every direct navigator.clipboard.writeText call site to use it
• The benefit is: every copy icon starts working for self-hosted HTTP users, future copy buttons inherit the fallback for free, and the existing duplicated fallback logic collapses to one audited implementation

What Changed

• New ui/src/lib/clipboard.ts exporting copyTextToClipboard(text: string): Promise<void>. Uses navigator.clipboard.writeText when both navigator.clipboard and window.isSecureContext are truthy; otherwise falls back to a transient on-screen-but-invisible textarea + document.execCommand("copy"). Rejects on failure so callers can surface a toast if they want to.
• Hardens the fallback vs. the two existing inlined copies: explicit focus({ preventScroll: true }) before .select() (some browsers won't honor programmatic selection without focus first), setSelectionRange(0, length) as a secondary selection path, on-screen-but-opacity: 0 + zIndex: -1 + pointerEvents: none positioning instead of left: -9999px (off-screen elements are silently excluded from the document selection in some engines), and restore-focus to the previously-focused element so users mid-typing aren't bumped out of their inputs.
• New co-located test file ui/src/lib/clipboard.test.ts — 9 tests covering the native-API happy path, the fallback mounting/selecting/removing the textarea, execCommand failure propagation, execCommand-throws cleanup, focus restoration, and the "secure context but no navigator.clipboard" degenerate case (jsdom-style).
• CopyText.tsx and CommentThread.tsx now import the shared utility and drop their inlined fallbacks. Their existing tests continue to pass unchanged.
• 14 direct navigator.clipboard.writeText(...) call sites across ui/src/components/ and ui/src/pages/ migrated to copyTextToClipboard(...). No behavioral changes beyond "now actually copies in non-secure contexts." Toast and copied-state feedback paths are untouched.

Verification

Automated:

• cd ui && pnpm tsc --noEmit → clean (exit 0).
• cd ui && pnpm vitest run → 346/346 tests pass, 65/65 files, including the new 9 clipboard tests and the pre-existing CommentThread.test.tsx (which has its own execCommand mocking).

Manual (on a self-hosted Paperclip reached over plain HTTP from another machine on the LAN):

• Before the fix, on a currently-broken button (e.g. "Copy Agent ID" from the agent detail overflow menu, or the copy icon next to the workspace path on CompanySkills): click → clipboard unchanged, no toast, menu item gives no feedback. The click is indistinguishable from a disabled button.
• After patching the running install's ui-dist/index.html with an equivalent inline polyfill and restarting the service: click "Copy Agent ID" → paste elsewhere confirms the UUID is on the clipboard. Spot-checked several other previously-broken buttons (workspace path copy, invite snippet copy, agent token copy on rotation) — all now land text on the clipboard.
• Also confirmed the native path still works on http://localhost:3100 (where navigator.clipboard is defined): utility short-circuits to navigator.clipboard.writeText, no textarea is ever mounted. The does not mount any DOM nodes unit test asserts this invariant so it can't silently regress.
• Verified the two already-fixed buttons (anything using CopyText, and "Copy as markdown" on comments which uses CopyMarkdownButton) continue to work identically after the refactor — their inlined fallbacks were replaced with calls to the shared utility, not behavior-changed.

Risks

Low. The fallback path is strictly opt-in-on-failure — it only runs when navigator.clipboard is missing or window.isSecureContext is false, so secure-context (HTTPS/localhost) behavior is identical to before this PR. The execCommand path is the same technique already shipping inline in CopyText and CommentThread; we're not introducing a new clipboard mechanism, just centralizing and hardening one. execCommand("copy") is deprecated but universally implemented (MDN flags it as deprecated for new code, not broken for existing calls). No schema, API, or public-contract changes.

Focus restoration is the one new behavior beyond the existing fallbacks — if a user had a textarea/input focused and clicked a copy button, focus now returns there after the copy (previously the off-screen textarea would steal focus). That's an ergonomic improvement rather than a regression risk, but worth flagging.

Model Used

Claude, claude-opus-4-6 (1M context window), with extended tool use for file reads, writes, and running vitest/tsc. No reasoning mode beyond the default.

Checklist

• I have included a thinking path that traces from project context to this change
• I have specified the model used (with version and capability details)
• I have run tests locally and they pass
• I have added or updated tests where applicable
• If this change affects the UI, I have included before/after screenshots — the visual behavior is unchanged in secure contexts, and the fix isn't meaningfully visual in non-secure contexts (before: click does nothing, icon doesn't animate, clipboard unchanged; after: icon flips to check, clipboard populated). Can add a screen recording of paste-target-before vs. paste-target-after if useful.
• I have updated relevant documentation to reflect my changes — no user-facing docs needed updating; the utility has inline documentation.
• I have considered and documented any risks above
• I will address all Greptile and reviewer comments before requesting merge

[greptile-apps]

Greptile Summary

Consolidates 15 scattered navigator.clipboard.writeText call sites — including two already-inlined fallbacks in CopyText and CommentThread — into a single shared copyTextToClipboard utility at ui/src/lib/clipboard.ts, and migrates every call site to use it. The fallback path is hardened over the prior inline copies (on-screen invisible textarea, explicit focus before select, setSelectionRange as a secondary selection, and focus restoration), and 9 unit tests cover the critical paths.

Confidence Score: 5/5

Safe to merge — all remaining findings are P2 improvement suggestions with no regressions to existing behaviour.

The change is purely additive in the non-secure-context path; secure-context behaviour is byte-for-byte identical to before. The one P2 flag (native API rejection not cascading to execCommand) is intentional and documented in the test suite. 346/346 tests pass, TypeScript is clean, and the fallback logic was already shipping inline across two components.

ui/src/lib/clipboard.ts — the native-API rejection fallback question is worth a quick decision before the utility is used by future callers.

Important Files Changed

Filename	Overview
ui/src/lib/clipboard.ts	New shared clipboard utility with secure-context detection and hardened execCommand fallback; native-API rejection doesn't cascade to the fallback path.
ui/src/lib/clipboard.test.ts	9 focused tests covering native path, fallback mounting/cleanup, execCommand failure propagation, focus restoration, and the missing-clipboard-in-secure-context edge case.
ui/src/components/CommentThread.tsx	Drops inline copyTextWithFallback in favour of the shared utility; logic and error-surface behaviour unchanged.
ui/src/components/CopyText.tsx	Removes duplicated inline fallback, delegates to copyTextToClipboard; @/ alias import consistent with existing style.
ui/src/components/IssueChatThread.tsx	Three navigator.clipboard.writeText call sites migrated; one (line 1157) still discards the promise with void and has no error feedback, matching pre-existing behaviour.
ui/src/pages/AgentDetail.tsx	Two call sites migrated; void-discarded promise pattern unchanged from before.
ui/src/components/IssueDocumentsSection.tsx	Single call site migrated with existing try/catch error handling intact.
ui/src/components/IssueProperties.tsx	Single call site migrated with existing try/catch error handling intact.
ui/src/components/IssueWorkspaceCard.tsx	Single call site migrated with existing try/catch error handling intact.
ui/src/components/WorktreeBanner.tsx	void + .then() pattern preserved; adds void keyword explicitly which is an improvement.
ui/src/pages/CompanySettings.tsx	Two call sites migrated; both wrapped in try/catch with toast feedback on success/failure.
ui/src/pages/CompanySkills.tsx	Single call site migrated; void-discarded promise with toast on success, matching prior behaviour.
ui/src/pages/IssueDetail.tsx	Single call site migrated; has existing try/catch with toast feedback.
ui/src/pages/RoutineDetail.tsx	Single call site migrated; has existing try/catch with success/error toasts.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: ui/src/lib/clipboard.ts
Line: 19-28

Comment:
**Native API rejection doesn't cascade to execCommand fallback**

If `navigator.clipboard.writeText` is present but rejects (e.g. the user clicked "Deny" on the browser's clipboard-permission prompt), the function rejects immediately without attempting the `execCommand` path. The test `"propagates rejection from the native API"` explicitly encodes this — so it's intentional — but it means the utility can fail silently in a secure context even when `execCommand` would have worked. Consider catching and retrying via the fallback, or at least documenting the intentional behaviour in the JSDoc above:

```typescript
    try {
      await navigator.clipboard.writeText(text);
      return;
    } catch {
      // fall through to execCommand fallback
    }
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(ui): make all copy-to-clipboard butt..." | Re-trigger Greptile}

[greptile-apps]

Native API rejection doesn't cascade to execCommand fallback

If navigator.clipboard.writeText is present but rejects (e.g. the user clicked "Deny" on the browser's clipboard-permission prompt), the function rejects immediately without attempting the execCommand path. The test "propagates rejection from the native API" explicitly encodes this — so it's intentional — but it means the utility can fail silently in a secure context even when execCommand would have worked. Consider catching and retrying via the fallback, or at least documenting the intentional behaviour in the JSDoc above:

    try {
      await navigator.clipboard.writeText(text);
      return;
    } catch {
      // fall through to execCommand fallback
    }

Prompt To Fix With AI

This is a comment left during a code review.
Path: ui/src/lib/clipboard.ts
Line: 19-28

Comment:
**Native API rejection doesn't cascade to execCommand fallback**

If `navigator.clipboard.writeText` is present but rejects (e.g. the user clicked "Deny" on the browser's clipboard-permission prompt), the function rejects immediately without attempting the `execCommand` path. The test `"propagates rejection from the native API"` explicitly encodes this — so it's intentional — but it means the utility can fail silently in a secure context even when `execCommand` would have worked. Consider catching and retrying via the fallback, or at least documenting the intentional behaviour in the JSDoc above:

```typescript
    try {
      await navigator.clipboard.writeText(text);
      return;
    } catch {
      // fall through to execCommand fallback
    }
```

How can I resolve this? If you propose a fix, please make it concise.

[joshdutcher]

Good call — applied in 8abefe7. The native-API call is now wrapped in try/catch and falls through to execCommand on rejection, with updated JSDoc documenting the cascade. Replaced the "propagates rejection from the native API" test with two: one asserting the cascade path (native rejects, execCommand succeeds → overall resolves), and one asserting the terminal case (both paths fail → rejects with the execCommand error). 347/347 tests pass.