fix(vscode): make message copy buttons reliable

[mjnaderi]

Route message and response copy actions through the VS Code extension host so webview focus changes do not block clipboard writes.

Issue

No linked issue. This fixes the focus-related copy-button failure described below.

Context

The message and response copy buttons previously called navigator.clipboard.writeText directly inside the webview. After switching focus away from VS Code and returning, that API could reject the clipboard write. The handlers would then exit before copying the text or displaying the check mark.

Implementation

Added a small clipboard context to kilo-ui. It defaults to navigator.clipboard for standalone consumers such as Storybook.

The shared VS Code provider overrides that implementation once for both the sidebar and Agent Manager. Copy requests are routed through the extension host and written using vscode.env.clipboard, avoiding the webview clipboard permission and focus behavior.

The existing Agent Manager clipboard message contract is reused. Sidebar requests are handled by the existing early-message router, keeping clipboard routing out of the main KiloProvider message switch.

Screenshots / Video

N/A — this is a behavior-only fix with no visual changes.

How to Test

Manual/local verification

• Built the extension and manually verified that copy still works after changing window focus.
• Ran bun test tests/unit/early-message.test.ts --dots; both clipboard-routing regression tests passed.
• Ran the extension typecheck, lint, formatter, check-kilocode-change, message-contract tests, and git diff --check; all passed.
• Pushed the original branch and confirmed that the pre-push hooks passed.

Reviewer test steps

1. Launch the development extension and create a new task.
2. Send a message and wait for the response.
3. Click “Copy message” and “Copy response”; confirm the expected text is copied and the corresponding check mark appears.
4. Switch to another application so VS Code loses focus.
5. Return to VS Code and click both copy buttons again.
6. Confirm both clipboard writes succeed and both buttons display their check marks.

Blocked checks and substitute verification

• Agent: bun run test:unit completed with 3,083 passing tests and one unrelated failure in WorktreeManager.resolveStartPoint, where an existing worktree fixture expected remote but received local-tracking. The failure reproduced when that test file was run in isolation. Substitute verification included the passing clipboard-routing regression tests, message-contract tests, typecheck, lint, formatting, and Kilo marker checks.

Checklist

• Issue linked above, or exception explained
• Tests/verification described
• Screenshots/video included for visual changes, or marked N/A
• Changeset considered for user-facing changes
• I personally reviewed the diff and can explain the changes, including any AI-assisted work.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (5 files)

• packages/kilo-vscode/src/kilo-provider/early-message.ts
• packages/kilo-vscode/tests/unit/early-message.test.ts
• packages/kilo-vscode/webview-ui/src/context/vscode.tsx
• packages/kilo-vscode/webview-ui/src/types/messages/extension-messages.ts
• packages/kilo-vscode/webview-ui/src/types/messages/webview-messages.ts

Previous Review Summary (commit 01fc303)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 01fc303)

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

WARNING

File	Line	Issue
packages/kilo-vscode/webview-ui/src/context/vscode.tsx	88	Clipboard success is reported before the extension-host write completes

Fix these issues in Kilo Cloud

Files Reviewed (8 files)

• .changeset/reliable-vscode-message-copy.md - 0 issues
• packages/kilo-ui/package.json - 0 issues
• packages/kilo-ui/src/components/message-part.tsx - 0 issues
• packages/kilo-ui/src/context/clipboard.tsx - 0 issues
• packages/kilo-vscode/src/KiloProvider.ts - 0 issues
• packages/kilo-vscode/src/kilo-provider/early-message.ts - 0 issues
• packages/kilo-vscode/tests/unit/early-message.test.ts - 0 issues
• packages/kilo-vscode/webview-ui/src/context/vscode.tsx - 1 issue

---

_{Reviewed by gpt-5.6-sol · Input: 61.6K · Output: 7.7K · Cached: 183.9K}

_{Review guidance: REVIEW.md from base branch main}

[johnnyeric]

Hey @mjnaderi, I couldn’t reproduce the issue described in the latest releases. Could you share the OS, Kilo version, and exact reproduction steps where you observed it? Also, please link any existing GitHub issue or user report for this problem.

[mjnaderi]

Hi @johnnyeric
I just tested with the latest Kilo VS Code extension, and the problem still exists.

OS: Linux (Arch Linux, kernel: 7.1.3-arch2-2, desktop: Gnome 50.3)
VS Code: 1.127.0
Kilo extension: 7.4.16

Reproduction steps:

• Send a message in Kilo VS Code extension.
• Click on copy button. It works.
• Switch to another window using alt+tab.
• Switch back to vs code. Don't click on anything.
• Click on copy button again (without clicking on anything else). It does not work.
• But if you first click on any other element in the extension view, the copy button works.

Related issue: #11092

[mjnaderi]

This note from MDN is for chrome browser extensions, but maybe applies here too.

Browser-specific considerations

In Chrome:

Chrome doesn't expose navigator.clipboard to extension service workers, and offscreen documents can't access navigator.clipboard due to the API's document focus requirements. As a result, Chrome extensions have to use the deprecated document.execCommand() APIs in an offscreen document or use navigator.clipboard in a different context, such as a content script or extension page. For page scripts to write to the clipboard without user interaction, the "clipboard-write" permission needs to be requested using the Web API navigator.permissions. Your extension can check for that permission using navigator.permissions.query():

[johnnyeric]

@mjnaderi Thanks for sharing all these details. I couldn't reproduce it on Mac but was able in a linux VM. The fix looks good thanks for working on this!