PR #24314 - manaflow-ai/cmux

Leo, 2026-10-22: "then is this merged yet: "cmd v anywhere in chat should put it in chat""
Leo, 2026-10-21: "pastes need to be able to paset even when the composer isn't litearlly focused.."

Leo-ask: ask-eb234d2036
Leo-ask: ask-a043d092b9

What was wrong

#24040 (67f77919331) routes ⌘V into the composer when the keyboard is anywhere else in a chat. It is on the current NEXT nightly (nightly-next 694c2a24da3, 1.0.0-nightly.3973494930601, published 2026-10-22 07:08 UTC). But its route lives in Composer (usePasteAnywhere), and the New Tab page (the default one-input screen NewTabScreen and the classic NewTabPage) never mounts Composer. It has its own field. So on a New Tab, with the keyboard on the page background, a row or a card, ⌘V did nothing.

Fix

Both New Tab pages install the same route (composer/pasteAnywhere.ts), aimed at their own field:

⌘V outside a text field moves the keyboard into the field, caret at the end;
a paste the page gets outside a field (Edit ▸ Paste) lands in the field: text goes after the draft, and an image becomes a chip through the page's existing intake;
another text field (a picker search, the rename field) keeps its own paste, and so does a modal dialog. This is ownsPaste, unchanged.

Per path, before and after

Where ⌘V lands, composer not focused	Before	After
Chat: transcript text, a message, a selection	composer (#24040)	same
Chat: empty space above/below the transcript, buttons, queue/running strip, context card	composer (#24040: any non-editable target)	same
Chat: popover with its own search field	that field keeps it (#24040 `ownsPaste`)	same
Chat: modal dialog	dialog keeps it	same
Chat: image or file paste	one chip (#24040)	same
New Tab (default screen): page background, rows, cards	nothing	field, caret at the end
New Tab (default screen): image paste outside the field	nothing	chip in the New Tab box
New Tab (classic page): page background, rows	nothing	field, caret at the end
New Tab: another text field focused	that field	same
Native: tab bar, sidebar row, header click	sidebar/tab bar clicks don't keep first responder; the focus model puts it back on the page, so the web keydown handler sees ⌘V	not changed here (see notes)

Tests

webviews/test/new-tab-paste-anywhere.test.ts: the real pane as a New Tab page, in Chromium and WebKit, for both designs (18 tests). On base, 14 fail and the 4 "another field keeps its paste" tests pass. With this change all 18 pass. The neighbours agent-pane-paste-anywhere.test.ts (12) and new-tab-paste-attachments.test.ts (6) still pass. scripts/web-lint.sh and prepush-gate.py are clean.

Notes

Native routing is not changed. PrimaryInputPasteRoute only covers Home's box, and no agent pane conforms to PrimaryInputTarget. When the sidebar list itself keeps first responder (SidebarListView.acceptsFirstResponder is true, for example with full keyboard access), menu ⌘V goes to the sidebar and never reaches the page. That is a separate Swift change, worth a follow-up if Leo still sees it after this lands.

Agent session: cosmic-gray

🤖 Generated with Claude Code

^{Need help on this PR? Tag @codesmith-bot with what you need.}

Summary by cubic

Makes Cmd-V paste into the New Tab field from anywhere on the page, matching how the chat composer behaves. Previously the paste-anywhere route (#24040) never ran on New Tab because its page has its own field and never mounts the composer, so Cmd-V with the keyboard on the background, a row, or a card did nothing.

Both New Tab designs (the one-input screen and the classic page) now install the same route aimed at their field: Cmd-V outside a text field moves the keyboard into the field with the caret at the end, and a paste the page receives lands there — text goes after the draft, an image becomes a chip. Other text fields keep their own paste.

Tests

Adds 18 browser tests covering both designs in Chromium and WebKit; 14 fail on base and all pass with the change.