fix(amicode): paste into the chat composer via the extension clipboard bridge by kateebonner · Pull Request #17 · harmoniqs/opencode

kateebonner · 2026-07-09T21:44:11Z

Problem

⌘V into the Amico chat composer did nothing — text copied elsewhere never appeared.

Root cause

The chat composer runs as a cross-origin iframe inside the VS Code webview, where the frame has no clipboard-read permission (the webview parent has none to delegate down). Two consequences:

navigator.clipboard / native paste deliver no data.
On ⌘V the browser dispatches no usable paste event to the frame — so hooking onPaste never fires.

The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is wired end-to-end (amicode/packages/extension/src/chat_panel.ts) but the chat composer never used it. Crucially, home-cards intercepts the ⌘V keydown — not the paste event — precisely because the paste event is dead in this context.

Fix

New readClipboardViaBridge() helper (clipboard-bridge.ts) — reuses the amicode postMessage protocol and self-gates to "" outside the webview, so web/desktop are untouched.
Primary path: intercept the ⌘V keydown in the composer (prompt-input.tsx), only when framed (inAmicode()), preventDefault, read via the bridge, and insert with addPart. The keystroke fires regardless of clipboard permission, so it bypasses the dead paste event.
Secondary path: an onPaste bridge fallback (readClipboardText in attachments.ts) covers context-menu paste.
No extension-side change — the clipboard-request responder already exists and is gated to the visible panel.

Testing

clipboard-bridge.test.ts — 4 unit tests (happy-dom): host round-trip, nonce-mismatch rejection, malformed reply, unframed no-op. ✅
tsgo -b typecheck ✅ · oxlint 0 errors ✅
Verified live in the VS Code extension: rebuilt the vendored opencode binary from this branch, reloaded the Extension Development Host, and ⌘V now pastes into the chat composer. ✅
No regression for web/desktop: the keydown path is gated off (inAmicode() false) and the bridge helper resolves "" immediately without posting.

…d bridge The chat composer runs as a cross-origin iframe inside the VS Code webview, where native paste and navigator.clipboard deliver no clipboard data (the webview parent has no clipboard-read permission to delegate down). handlePaste called event.preventDefault() and then read event.clipboardData.getData(), which comes back empty in that context — so it bailed and inserted nothing, and Cmd+V appeared to do nothing in the chat box. The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is fully wired end-to-end (chat_panel.ts) but the main chat composer never used it. Add a readClipboardViaBridge() helper (mirrors the home-cards fallback, reuses the amicode postMessage protocol, self-gates to "" outside the webview) and inject it into createPromptAttachments as readClipboardText, used as a fallback in handlePaste when native paste yields no text. No extension-side change: the responder already exists and is gated to the visible panel. Unit-tested (clipboard-bridge.test.ts); no regression for web/desktop where the helper resolves "" immediately without posting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The first pass hooked the paste EVENT (onPaste → readClipboardText fallback), but in the VS Code webview iframe the frame has no clipboard-read permission, so the browser dispatches no usable paste event on ⌘V — handlePaste never runs and the fallback never fires. That's why paste still did nothing in the chat. Mirror the fork's working approach (home-cards pasteFallback): intercept the ⌘V keydown directly (only when framed, via inAmicode()), preventDefault, read the OS clipboard over the extension bridge, and insert via addPart. The keystroke fires regardless of clipboard permission, so this bypasses the dead paste event. The onPaste readClipboardText fallback stays for context-menu paste; native web/desktop paste is untouched (inAmicode() gates the keydown path off there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

kateebonner · 2026-07-09T21:44:11Z

Problem

⌘V into the Amico chat composer did nothing — text copied elsewhere never appeared.

Root cause

The chat composer runs as a cross-origin iframe inside the VS Code webview, where the frame has no clipboard-read permission (the webview parent has none to delegate down). Two consequences:

navigator.clipboard / native paste deliver no data.
On ⌘V the browser dispatches no usable paste event to the frame — so hooking onPaste never fires.

The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is wired end-to-end (amicode/packages/extension/src/chat_panel.ts) but the chat composer never used it. Crucially, home-cards intercepts the ⌘V keydown — not the paste event — precisely because the paste event is dead in this context.

Fix

New readClipboardViaBridge() helper (clipboard-bridge.ts) — reuses the amicode postMessage protocol and self-gates to "" outside the webview, so web/desktop are untouched.
Primary path: intercept the ⌘V keydown in the composer (prompt-input.tsx), only when framed (inAmicode()), preventDefault, read via the bridge, and insert with addPart. The keystroke fires regardless of clipboard permission, so it bypasses the dead paste event.
Secondary path: an onPaste bridge fallback (readClipboardText in attachments.ts) covers context-menu paste.
No extension-side change — the clipboard-request responder already exists and is gated to the visible panel.

Testing

clipboard-bridge.test.ts — 4 unit tests (happy-dom): host round-trip, nonce-mismatch rejection, malformed reply, unframed no-op. ✅
tsgo -b typecheck ✅ · oxlint 0 errors ✅
Verified live in the VS Code extension: rebuilt the vendored opencode binary from this branch, reloaded the Extension Development Host, and ⌘V now pastes into the chat composer. ✅
No regression for web/desktop: the keydown path is gated off (inAmicode() false) and the bridge helper resolves "" immediately without posting.

…d bridge The chat composer runs as a cross-origin iframe inside the VS Code webview, where native paste and navigator.clipboard deliver no clipboard data (the webview parent has no clipboard-read permission to delegate down). handlePaste called event.preventDefault() and then read event.clipboardData.getData(), which comes back empty in that context — so it bailed and inserted nothing, and Cmd+V appeared to do nothing in the chat box. The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is fully wired end-to-end (chat_panel.ts) but the main chat composer never used it. Add a readClipboardViaBridge() helper (mirrors the home-cards fallback, reuses the amicode postMessage protocol, self-gates to "" outside the webview) and inject it into createPromptAttachments as readClipboardText, used as a fallback in handlePaste when native paste yields no text. No extension-side change: the responder already exists and is gated to the visible panel. Unit-tested (clipboard-bridge.test.ts); no regression for web/desktop where the helper resolves "" immediately without posting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The first pass hooked the paste EVENT (onPaste → readClipboardText fallback), but in the VS Code webview iframe the frame has no clipboard-read permission, so the browser dispatches no usable paste event on ⌘V — handlePaste never runs and the fallback never fires. That's why paste still did nothing in the chat. Mirror the fork's working approach (home-cards pasteFallback): intercept the ⌘V keydown directly (only when framed, via inAmicode()), preventDefault, read the OS clipboard over the extension bridge, and insert via addPart. The keystroke fires regardless of clipboard permission, so this bypasses the dead paste event. The onPaste readClipboardText fallback stays for context-menu paste; native web/desktop paste is untouched (inAmicode() gates the keydown path off there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

kateebonner · 2026-07-09T21:44:11Z

Problem

⌘V into the Amico chat composer did nothing — text copied elsewhere never appeared.

Root cause

The chat composer runs as a cross-origin iframe inside the VS Code webview, where the frame has no clipboard-read permission (the webview parent has none to delegate down). Two consequences:

navigator.clipboard / native paste deliver no data.
On ⌘V the browser dispatches no usable paste event to the frame — so hooking onPaste never fires.

The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is wired end-to-end (amicode/packages/extension/src/chat_panel.ts) but the chat composer never used it. Crucially, home-cards intercepts the ⌘V keydown — not the paste event — precisely because the paste event is dead in this context.

Fix

New readClipboardViaBridge() helper (clipboard-bridge.ts) — reuses the amicode postMessage protocol and self-gates to "" outside the webview, so web/desktop are untouched.
Primary path: intercept the ⌘V keydown in the composer (prompt-input.tsx), only when framed (inAmicode()), preventDefault, read via the bridge, and insert with addPart. The keystroke fires regardless of clipboard permission, so it bypasses the dead paste event.
Secondary path: an onPaste bridge fallback (readClipboardText in attachments.ts) covers context-menu paste.
No extension-side change — the clipboard-request responder already exists and is gated to the visible panel.

Testing

clipboard-bridge.test.ts — 4 unit tests (happy-dom): host round-trip, nonce-mismatch rejection, malformed reply, unframed no-op. ✅
tsgo -b typecheck ✅ · oxlint 0 errors ✅
Verified live in the VS Code extension: rebuilt the vendored opencode binary from this branch, reloaded the Extension Development Host, and ⌘V now pastes into the chat composer. ✅
No regression for web/desktop: the keydown path is gated off (inAmicode() false) and the bridge helper resolves "" immediately without posting.

…d bridge The chat composer runs as a cross-origin iframe inside the VS Code webview, where native paste and navigator.clipboard deliver no clipboard data (the webview parent has no clipboard-read permission to delegate down). handlePaste called event.preventDefault() and then read event.clipboardData.getData(), which comes back empty in that context — so it bailed and inserted nothing, and Cmd+V appeared to do nothing in the chat box. The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is fully wired end-to-end (chat_panel.ts) but the main chat composer never used it. Add a readClipboardViaBridge() helper (mirrors the home-cards fallback, reuses the amicode postMessage protocol, self-gates to "" outside the webview) and inject it into createPromptAttachments as readClipboardText, used as a fallback in handlePaste when native paste yields no text. No extension-side change: the responder already exists and is gated to the visible panel. Unit-tested (clipboard-bridge.test.ts); no regression for web/desktop where the helper resolves "" immediately without posting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The first pass hooked the paste EVENT (onPaste → readClipboardText fallback), but in the VS Code webview iframe the frame has no clipboard-read permission, so the browser dispatches no usable paste event on ⌘V — handlePaste never runs and the fallback never fires. That's why paste still did nothing in the chat. Mirror the fork's working approach (home-cards pasteFallback): intercept the ⌘V keydown directly (only when framed, via inAmicode()), preventDefault, read the OS clipboard over the extension bridge, and insert via addPart. The keystroke fires regardless of clipboard permission, so this bypasses the dead paste event. The onPaste readClipboardText fallback stays for context-menu paste; native web/desktop paste is untouched (inAmicode() gates the keydown path off there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

kateebonner · 2026-07-09T21:44:11Z

Problem

⌘V into the Amico chat composer did nothing — text copied elsewhere never appeared.

Root cause

The chat composer runs as a cross-origin iframe inside the VS Code webview, where the frame has no clipboard-read permission (the webview parent has none to delegate down). Two consequences:

navigator.clipboard / native paste deliver no data.
On ⌘V the browser dispatches no usable paste event to the frame — so hooking onPaste never fires.

The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is wired end-to-end (amicode/packages/extension/src/chat_panel.ts) but the chat composer never used it. Crucially, home-cards intercepts the ⌘V keydown — not the paste event — precisely because the paste event is dead in this context.

Fix

New readClipboardViaBridge() helper (clipboard-bridge.ts) — reuses the amicode postMessage protocol and self-gates to "" outside the webview, so web/desktop are untouched.
Primary path: intercept the ⌘V keydown in the composer (prompt-input.tsx), only when framed (inAmicode()), preventDefault, read via the bridge, and insert with addPart. The keystroke fires regardless of clipboard permission, so it bypasses the dead paste event.
Secondary path: an onPaste bridge fallback (readClipboardText in attachments.ts) covers context-menu paste.
No extension-side change — the clipboard-request responder already exists and is gated to the visible panel.

Testing

clipboard-bridge.test.ts — 4 unit tests (happy-dom): host round-trip, nonce-mismatch rejection, malformed reply, unframed no-op. ✅
tsgo -b typecheck ✅ · oxlint 0 errors ✅
Verified live in the VS Code extension: rebuilt the vendored opencode binary from this branch, reloaded the Extension Development Host, and ⌘V now pastes into the chat composer. ✅
No regression for web/desktop: the keydown path is gated off (inAmicode() false) and the bridge helper resolves "" immediately without posting.

…d bridge The chat composer runs as a cross-origin iframe inside the VS Code webview, where native paste and navigator.clipboard deliver no clipboard data (the webview parent has no clipboard-read permission to delegate down). handlePaste called event.preventDefault() and then read event.clipboardData.getData(), which comes back empty in that context — so it bailed and inserted nothing, and Cmd+V appeared to do nothing in the chat box. The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is fully wired end-to-end (chat_panel.ts) but the main chat composer never used it. Add a readClipboardViaBridge() helper (mirrors the home-cards fallback, reuses the amicode postMessage protocol, self-gates to "" outside the webview) and inject it into createPromptAttachments as readClipboardText, used as a fallback in handlePaste when native paste yields no text. No extension-side change: the responder already exists and is gated to the visible panel. Unit-tested (clipboard-bridge.test.ts); no regression for web/desktop where the helper resolves "" immediately without posting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The first pass hooked the paste EVENT (onPaste → readClipboardText fallback), but in the VS Code webview iframe the frame has no clipboard-read permission, so the browser dispatches no usable paste event on ⌘V — handlePaste never runs and the fallback never fires. That's why paste still did nothing in the chat. Mirror the fork's working approach (home-cards pasteFallback): intercept the ⌘V keydown directly (only when framed, via inAmicode()), preventDefault, read the OS clipboard over the extension bridge, and insert via addPart. The keystroke fires regardless of clipboard permission, so this bypasses the dead paste event. The onPaste readClipboardText fallback stays for context-menu paste; native web/desktop paste is untouched (inAmicode() gates the keydown path off there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

kateebonner · 2026-07-09T21:44:11Z

Problem

⌘V into the Amico chat composer did nothing — text copied elsewhere never appeared.

Root cause

The chat composer runs as a cross-origin iframe inside the VS Code webview, where the frame has no clipboard-read permission (the webview parent has none to delegate down). Two consequences:

navigator.clipboard / native paste deliver no data.
On ⌘V the browser dispatches no usable paste event to the frame — so hooking onPaste never fires.

The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is wired end-to-end (amicode/packages/extension/src/chat_panel.ts) but the chat composer never used it. Crucially, home-cards intercepts the ⌘V keydown — not the paste event — precisely because the paste event is dead in this context.

Fix

New readClipboardViaBridge() helper (clipboard-bridge.ts) — reuses the amicode postMessage protocol and self-gates to "" outside the webview, so web/desktop are untouched.
Primary path: intercept the ⌘V keydown in the composer (prompt-input.tsx), only when framed (inAmicode()), preventDefault, read via the bridge, and insert with addPart. The keystroke fires regardless of clipboard permission, so it bypasses the dead paste event.
Secondary path: an onPaste bridge fallback (readClipboardText in attachments.ts) covers context-menu paste.
No extension-side change — the clipboard-request responder already exists and is gated to the visible panel.

Testing

clipboard-bridge.test.ts — 4 unit tests (happy-dom): host round-trip, nonce-mismatch rejection, malformed reply, unframed no-op. ✅
tsgo -b typecheck ✅ · oxlint 0 errors ✅
Verified live in the VS Code extension: rebuilt the vendored opencode binary from this branch, reloaded the Extension Development Host, and ⌘V now pastes into the chat composer. ✅
No regression for web/desktop: the keydown path is gated off (inAmicode() false) and the bridge helper resolves "" immediately without posting.

…d bridge The chat composer runs as a cross-origin iframe inside the VS Code webview, where native paste and navigator.clipboard deliver no clipboard data (the webview parent has no clipboard-read permission to delegate down). handlePaste called event.preventDefault() and then read event.clipboardData.getData(), which comes back empty in that context — so it bailed and inserted nothing, and Cmd+V appeared to do nothing in the chat box. The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is fully wired end-to-end (chat_panel.ts) but the main chat composer never used it. Add a readClipboardViaBridge() helper (mirrors the home-cards fallback, reuses the amicode postMessage protocol, self-gates to "" outside the webview) and inject it into createPromptAttachments as readClipboardText, used as a fallback in handlePaste when native paste yields no text. No extension-side change: the responder already exists and is gated to the visible panel. Unit-tested (clipboard-bridge.test.ts); no regression for web/desktop where the helper resolves "" immediately without posting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The first pass hooked the paste EVENT (onPaste → readClipboardText fallback), but in the VS Code webview iframe the frame has no clipboard-read permission, so the browser dispatches no usable paste event on ⌘V — handlePaste never runs and the fallback never fires. That's why paste still did nothing in the chat. Mirror the fork's working approach (home-cards pasteFallback): intercept the ⌘V keydown directly (only when framed, via inAmicode()), preventDefault, read the OS clipboard over the extension bridge, and insert via addPart. The keystroke fires regardless of clipboard permission, so this bypasses the dead paste event. The onPaste readClipboardText fallback stays for context-menu paste; native web/desktop paste is untouched (inAmicode() gates the keydown path off there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

kateebonner · 2026-07-09T21:44:11Z

Problem

⌘V into the Amico chat composer did nothing — text copied elsewhere never appeared.

Root cause

The chat composer runs as a cross-origin iframe inside the VS Code webview, where the frame has no clipboard-read permission (the webview parent has none to delegate down). Two consequences:

navigator.clipboard / native paste deliver no data.
On ⌘V the browser dispatches no usable paste event to the frame — so hooking onPaste never fires.

The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is wired end-to-end (amicode/packages/extension/src/chat_panel.ts) but the chat composer never used it. Crucially, home-cards intercepts the ⌘V keydown — not the paste event — precisely because the paste event is dead in this context.

Fix

New readClipboardViaBridge() helper (clipboard-bridge.ts) — reuses the amicode postMessage protocol and self-gates to "" outside the webview, so web/desktop are untouched.
Primary path: intercept the ⌘V keydown in the composer (prompt-input.tsx), only when framed (inAmicode()), preventDefault, read via the bridge, and insert with addPart. The keystroke fires regardless of clipboard permission, so it bypasses the dead paste event.
Secondary path: an onPaste bridge fallback (readClipboardText in attachments.ts) covers context-menu paste.
No extension-side change — the clipboard-request responder already exists and is gated to the visible panel.

Testing

clipboard-bridge.test.ts — 4 unit tests (happy-dom): host round-trip, nonce-mismatch rejection, malformed reply, unframed no-op. ✅
tsgo -b typecheck ✅ · oxlint 0 errors ✅
Verified live in the VS Code extension: rebuilt the vendored opencode binary from this branch, reloaded the Extension Development Host, and ⌘V now pastes into the chat composer. ✅
No regression for web/desktop: the keydown path is gated off (inAmicode() false) and the bridge helper resolves "" immediately without posting.

…d bridge The chat composer runs as a cross-origin iframe inside the VS Code webview, where native paste and navigator.clipboard deliver no clipboard data (the webview parent has no clipboard-read permission to delegate down). handlePaste called event.preventDefault() and then read event.clipboardData.getData(), which comes back empty in that context — so it bailed and inserted nothing, and Cmd+V appeared to do nothing in the chat box. The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is fully wired end-to-end (chat_panel.ts) but the main chat composer never used it. Add a readClipboardViaBridge() helper (mirrors the home-cards fallback, reuses the amicode postMessage protocol, self-gates to "" outside the webview) and inject it into createPromptAttachments as readClipboardText, used as a fallback in handlePaste when native paste yields no text. No extension-side change: the responder already exists and is gated to the visible panel. Unit-tested (clipboard-bridge.test.ts); no regression for web/desktop where the helper resolves "" immediately without posting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The first pass hooked the paste EVENT (onPaste → readClipboardText fallback), but in the VS Code webview iframe the frame has no clipboard-read permission, so the browser dispatches no usable paste event on ⌘V — handlePaste never runs and the fallback never fires. That's why paste still did nothing in the chat. Mirror the fork's working approach (home-cards pasteFallback): intercept the ⌘V keydown directly (only when framed, via inAmicode()), preventDefault, read the OS clipboard over the extension bridge, and insert via addPart. The keystroke fires regardless of clipboard permission, so this bypasses the dead paste event. The onPaste readClipboardText fallback stays for context-menu paste; native web/desktop paste is untouched (inAmicode() gates the keydown path off there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

kateebonner · 2026-07-09T21:44:11Z

Problem

⌘V into the Amico chat composer did nothing — text copied elsewhere never appeared.

Root cause

The chat composer runs as a cross-origin iframe inside the VS Code webview, where the frame has no clipboard-read permission (the webview parent has none to delegate down). Two consequences:

navigator.clipboard / native paste deliver no data.
On ⌘V the browser dispatches no usable paste event to the frame — so hooking onPaste never fires.

The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is wired end-to-end (amicode/packages/extension/src/chat_panel.ts) but the chat composer never used it. Crucially, home-cards intercepts the ⌘V keydown — not the paste event — precisely because the paste event is dead in this context.

Fix

New readClipboardViaBridge() helper (clipboard-bridge.ts) — reuses the amicode postMessage protocol and self-gates to "" outside the webview, so web/desktop are untouched.
Primary path: intercept the ⌘V keydown in the composer (prompt-input.tsx), only when framed (inAmicode()), preventDefault, read via the bridge, and insert with addPart. The keystroke fires regardless of clipboard permission, so it bypasses the dead paste event.
Secondary path: an onPaste bridge fallback (readClipboardText in attachments.ts) covers context-menu paste.
No extension-side change — the clipboard-request responder already exists and is gated to the visible panel.

Testing

clipboard-bridge.test.ts — 4 unit tests (happy-dom): host round-trip, nonce-mismatch rejection, malformed reply, unframed no-op. ✅
tsgo -b typecheck ✅ · oxlint 0 errors ✅
Verified live in the VS Code extension: rebuilt the vendored opencode binary from this branch, reloaded the Extension Development Host, and ⌘V now pastes into the chat composer. ✅
No regression for web/desktop: the keydown path is gated off (inAmicode() false) and the bridge helper resolves "" immediately without posting.

…d bridge The chat composer runs as a cross-origin iframe inside the VS Code webview, where native paste and navigator.clipboard deliver no clipboard data (the webview parent has no clipboard-read permission to delegate down). handlePaste called event.preventDefault() and then read event.clipboardData.getData(), which comes back empty in that context — so it bailed and inserted nothing, and Cmd+V appeared to do nothing in the chat box. The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is fully wired end-to-end (chat_panel.ts) but the main chat composer never used it. Add a readClipboardViaBridge() helper (mirrors the home-cards fallback, reuses the amicode postMessage protocol, self-gates to "" outside the webview) and inject it into createPromptAttachments as readClipboardText, used as a fallback in handlePaste when native paste yields no text. No extension-side change: the responder already exists and is gated to the visible panel. Unit-tested (clipboard-bridge.test.ts); no regression for web/desktop where the helper resolves "" immediately without posting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The first pass hooked the paste EVENT (onPaste → readClipboardText fallback), but in the VS Code webview iframe the frame has no clipboard-read permission, so the browser dispatches no usable paste event on ⌘V — handlePaste never runs and the fallback never fires. That's why paste still did nothing in the chat. Mirror the fork's working approach (home-cards pasteFallback): intercept the ⌘V keydown directly (only when framed, via inAmicode()), preventDefault, read the OS clipboard over the extension bridge, and insert via addPart. The keystroke fires regardless of clipboard permission, so this bypasses the dead paste event. The onPaste readClipboardText fallback stays for context-menu paste; native web/desktop paste is untouched (inAmicode() gates the keydown path off there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

kateebonner · 2026-07-09T21:44:11Z

Problem

⌘V into the Amico chat composer did nothing — text copied elsewhere never appeared.

Root cause

The chat composer runs as a cross-origin iframe inside the VS Code webview, where the frame has no clipboard-read permission (the webview parent has none to delegate down). Two consequences:

navigator.clipboard / native paste deliver no data.
On ⌘V the browser dispatches no usable paste event to the frame — so hooking onPaste never fires.

The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is wired end-to-end (amicode/packages/extension/src/chat_panel.ts) but the chat composer never used it. Crucially, home-cards intercepts the ⌘V keydown — not the paste event — precisely because the paste event is dead in this context.

Fix

New readClipboardViaBridge() helper (clipboard-bridge.ts) — reuses the amicode postMessage protocol and self-gates to "" outside the webview, so web/desktop are untouched.
Primary path: intercept the ⌘V keydown in the composer (prompt-input.tsx), only when framed (inAmicode()), preventDefault, read via the bridge, and insert with addPart. The keystroke fires regardless of clipboard permission, so it bypasses the dead paste event.
Secondary path: an onPaste bridge fallback (readClipboardText in attachments.ts) covers context-menu paste.
No extension-side change — the clipboard-request responder already exists and is gated to the visible panel.

Testing

clipboard-bridge.test.ts — 4 unit tests (happy-dom): host round-trip, nonce-mismatch rejection, malformed reply, unframed no-op. ✅
tsgo -b typecheck ✅ · oxlint 0 errors ✅
Verified live in the VS Code extension: rebuilt the vendored opencode binary from this branch, reloaded the Extension Development Host, and ⌘V now pastes into the chat composer. ✅
No regression for web/desktop: the keydown path is gated off (inAmicode() false) and the bridge helper resolves "" immediately without posting.

…d bridge The chat composer runs as a cross-origin iframe inside the VS Code webview, where native paste and navigator.clipboard deliver no clipboard data (the webview parent has no clipboard-read permission to delegate down). handlePaste called event.preventDefault() and then read event.clipboardData.getData(), which comes back empty in that context — so it bailed and inserted nothing, and Cmd+V appeared to do nothing in the chat box. The fork already solved this for the onboarding profile inputs (home-cards.tsx) with an extension clipboard bridge: the iframe posts a clipboard-request, the extension host reads vscode.env.clipboard and replies. That bridge is fully wired end-to-end (chat_panel.ts) but the main chat composer never used it. Add a readClipboardViaBridge() helper (mirrors the home-cards fallback, reuses the amicode postMessage protocol, self-gates to "" outside the webview) and inject it into createPromptAttachments as readClipboardText, used as a fallback in handlePaste when native paste yields no text. No extension-side change: the responder already exists and is gated to the visible panel. Unit-tested (clipboard-bridge.test.ts); no regression for web/desktop where the helper resolves "" immediately without posting. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

The first pass hooked the paste EVENT (onPaste → readClipboardText fallback), but in the VS Code webview iframe the frame has no clipboard-read permission, so the browser dispatches no usable paste event on ⌘V — handlePaste never runs and the fallback never fires. That's why paste still did nothing in the chat. Mirror the fork's working approach (home-cards pasteFallback): intercept the ⌘V keydown directly (only when framed, via inAmicode()), preventDefault, read the OS clipboard over the extension bridge, and insert via addPart. The keystroke fires regardless of clipboard permission, so this bypasses the dead paste event. The onPaste readClipboardText fallback stays for context-menu paste; native web/desktop paste is untouched (inAmicode() gates the keydown path off there). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>