You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(vscode): keep transcript selection on copy in VS Code 1.143 - #15472
In VS Code 1.143, selected text in the Kilo chat transcript cannot be copied with Cmd/Ctrl+C or with right-click > Copy. The selection clears, focus moves to the prompt, and the clipboard keeps its old content. The per-message Copy button still works. This affects the sidebar, Agent Manager and editor chat tabs on macOS, Windows and Linux.
Related: #15457 (same Cmd+C failure; the Cmd+A part of that issue was not verified).
Why This Change Was Made
The cause is in VS Code, not in a Kilo release. microsoft/vscode#341552 (commit f5f64f0, shipped in 1.143.0) changed the webview host. It now records the last focused element in the webview. Before a native clipboard command (execCommand), it focuses that element again if focus is on the document body.
Transcript text is not focusable, so after a mouse selection the focus is on the body. The last focused element is almost always the prompt textarea. VS Code focuses the textarea, the selection collapses, and Copy copies nothing. Upstream issue: microsoft/vscode#344028 (open, no milestone; VS Code main still has the change).
The fix gives the transcript container tabIndex={-1}. A mouse press inside the transcript now moves focus to the transcript (native browser behavior), so VS Code records a non-editable element and does not move focus to the prompt. tabIndex={-1} keeps the transcript out of the Tab order. Mouse focus does not show a focus ring.
The change is in MessageList, so it covers the sidebar, Agent Manager and editor chat tabs. It does not depend on the VS Code version.
User Impact
Cmd/Ctrl+C and right-click > Copy work again for selected transcript text in VS Code 1.143.
After a click in the transcript, the webview no longer moves focus back to the prompt by itself when the VS Code window becomes active again. The extension restoreInput path is not changed.
Evidence
Real Kilo UI with the vscode-self-test harness. Each run: click the prompt, drag-select transcript text, press Cmd+C, read the clipboard with pbpaste. Before and after use the same origin/main build with only this change removed or added.
VS Code
Surface
Without fix
With fix
1.143.1
Sidebar, code block
Selection cleared, focus on prompt, clipboard unchanged
Selection kept, clipboard = selected code
1.143.1
Sidebar, paragraph
Selection cleared, clipboard unchanged
Clipboard = selected text
1.143.1
Agent Manager
Selection cleared, clipboard unchanged
Selection kept, clipboard = selected text
1.141.0
Sidebar, code block
Copy works (VS Code change not present)
Copy works
A focus trace on 1.143.1 without the fix shows VS Code's own webview host (index.html, execCommand handler) calls textarea.focus() between the Cmd+C keydown and the copy event. Kilo's own focus restore code does not run during the copy.
Other checks:
New Playwright test tests/transcript-copy.spec.ts: fails without the fix, passes with it.
bun run compile (typecheck and lint): pass.
bun run test:unit: 6965 pass, 2 skip, 0 fail.
No focus ring after a mouse click in the transcript (checked by screenshot and computed style).
Not tested: right-click > Copy (the macOS context menu is native and the harness cannot click it; it uses the same webview.copy() > execCommand path as Cmd+C), Windows and Linux.
The tabIndex={-1} fix is sound: it makes the transcript a mouse-focusable, non-editable target so VS Code 1.143 refocuses it instead of the prompt before a native Copy, and -1 keeps it out of the Tab order. The new Playwright test exercises the real mechanism (focus lands on .message-list after a drag selection) and uses an existing story, so no new story or baseline is needed.
The only gap is release hygiene: this PR fixes six user-facing issues in the VS Code extension but ships without a .changeset/*.md entry, unlike comparable vscode fixes in this repo (e.g. .changeset/browser-open-always-allow.md). A short user-facing changeset would give the fix release notes and a kilo-code version bump.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Problem This Solves
In VS Code 1.143, selected text in the Kilo chat transcript cannot be copied with Cmd/Ctrl+C or with right-click > Copy. The selection clears, focus moves to the prompt, and the clipboard keeps its old content. The per-message Copy button still works. This affects the sidebar, Agent Manager and editor chat tabs on macOS, Windows and Linux.
Fixes #15379
Fixes #15382
Fixes #15394
Fixes #15446
Fixes #15449
Fixes #15455
Related: #15457 (same Cmd+C failure; the Cmd+A part of that issue was not verified).
Why This Change Was Made
The cause is in VS Code, not in a Kilo release. microsoft/vscode#341552 (commit
f5f64f0, shipped in 1.143.0) changed the webview host. It now records the last focused element in the webview. Before a native clipboard command (execCommand), it focuses that element again if focus is on the document body.Transcript text is not focusable, so after a mouse selection the focus is on the body. The last focused element is almost always the prompt textarea. VS Code focuses the textarea, the selection collapses, and Copy copies nothing. Upstream issue: microsoft/vscode#344028 (open, no milestone; VS Code
mainstill has the change).The fix gives the transcript container
tabIndex={-1}. A mouse press inside the transcript now moves focus to the transcript (native browser behavior), so VS Code records a non-editable element and does not move focus to the prompt.tabIndex={-1}keeps the transcript out of the Tab order. Mouse focus does not show a focus ring.The change is in
MessageList, so it covers the sidebar, Agent Manager and editor chat tabs. It does not depend on the VS Code version.User Impact
restoreInputpath is not changed.Evidence
Real Kilo UI with the
vscode-self-testharness. Each run: click the prompt, drag-select transcript text, press Cmd+C, read the clipboard withpbpaste. Before and after use the sameorigin/mainbuild with only this change removed or added.A focus trace on 1.143.1 without the fix shows VS Code's own webview host (
index.html,execCommandhandler) callstextarea.focus()between the Cmd+C keydown and thecopyevent. Kilo's own focus restore code does not run during the copy.Other checks:
tests/transcript-copy.spec.ts: fails without the fix, passes with it.bun run compile(typecheck and lint): pass.bun run test:unit: 6965 pass, 2 skip, 0 fail.Not tested: right-click > Copy (the macOS context menu is native and the harness cannot click it; it uses the same
webview.copy()>execCommandpath as Cmd+C), Windows and Linux.