[PR #13871] fix: handle text clipboard paste on Ctrl+V for Windows terminals #14851

Open
opened 2026-02-16 18:19:36 -05:00 by yindo · 0 comments
Owner

Original Pull Request: https://github.com/anomalyco/opencode/pull/13871

State: open
Merged: No


Fixes this issue #13800

Summary

On Windows 11, pressing Ctrl+V in the TUI prompt does not paste text. This PR fixes the issue by directly reading clipboard text when Ctrl+V is pressed, instead of relying solely on bracketed paste sequences that Windows terminals don't reliably emit.

Root Cause

The onKeyDown handler for input_paste (Ctrl+V) in prompt/index.tsx calls Clipboard.read(), which successfully reads both images and text from the clipboard. However, only the image/* case was handled — for text content, the handler fell through expecting the terminal to emit a bracketed paste sequence. Windows Terminal, cmd, and PowerShell do not reliably send bracketed paste sequences for Ctrl+V key presses, causing text paste to silently fail.

Fix

clipboard.ts: Added Clipboard.readText() — a dedicated text reader that uses clipboardy.read() and normalizes CRLF/CR line endings to LF.

prompt/index.tsx: Modified the Ctrl+V handler to also handle text/plain content from Clipboard.read():

  • Prevents the default event to avoid double-paste
  • Normalizes CRLF → LF (Windows clipboard often uses CRLF)
  • Routes through the same paste pipeline as onPaste: file path detection, image file handling, large paste summarization (≥3 lines or >150 chars), and direct insertion for short text
  • Falls through to bracketed paste only if clipboard is completely empty (no regression for terminals that do support it)

Testing

  • 18 new unit tests covering clipboard text reading, CRLF normalization, and paste pipeline logic
  • Full test suite: 909 pass, 0 regressions
  • No changes to image paste behavior
  • Bracketed paste (onPaste) path is fully preserved

Notes for Reviewers

  1. No regression on macOS/Linux: The text clipboard read path now runs on all platforms when Ctrl+V is pressed. On macOS/Linux where bracketed paste works, the Ctrl+V handler will read the same text that would have arrived via bracketed paste — the user sees the same result either way.
  2. Image paste preserved: Image check runs first (unchanged) — only if no image is found does the text path execute.
  3. Manual Windows verification: To fully validate on Windows 11, run the TUI and press Ctrl+V with text in the clipboard. Verify text appears in the prompt. Test with multiline text (should show [Pasted ~N lines] summary). Test with an image in the clipboard (should still paste as image).
**Original Pull Request:** https://github.com/anomalyco/opencode/pull/13871 **State:** open **Merged:** No --- Fixes this issue #13800 ## Summary On Windows 11, pressing Ctrl+V in the TUI prompt does not paste text. This PR fixes the issue by directly reading clipboard text when Ctrl+V is pressed, instead of relying solely on bracketed paste sequences that Windows terminals don't reliably emit. ## Root Cause The `onKeyDown` handler for `input_paste` (Ctrl+V) in [prompt/index.tsx](cci:7://file:///Users/venom/opencode/packages/opencode/src/cli/cmd/tui/component/prompt/index.tsx:0:0-0:0) calls `Clipboard.read()`, which successfully reads both images and text from the clipboard. However, only the `image/*` case was handled — for text content, the handler fell through expecting the terminal to emit a bracketed paste sequence. Windows Terminal, cmd, and PowerShell do not reliably send bracketed paste sequences for Ctrl+V key presses, causing text paste to silently fail. ## Fix **[clipboard.ts](cci:7://file:///Users/venom/opencode/packages/opencode/src/cli/cmd/tui/util/clipboard.ts:0:0-0:0)**: Added `Clipboard.readText()` — a dedicated text reader that uses `clipboardy.read()` and normalizes CRLF/CR line endings to LF. **[prompt/index.tsx](cci:7://file:///Users/venom/opencode/packages/opencode/src/cli/cmd/tui/component/prompt/index.tsx:0:0-0:0)**: Modified the Ctrl+V handler to also handle `text/plain` content from `Clipboard.read()`: - Prevents the default event to avoid double-paste - Normalizes CRLF → LF (Windows clipboard often uses CRLF) - Routes through the same paste pipeline as `onPaste`: file path detection, image file handling, large paste summarization (≥3 lines or >150 chars), and direct insertion for short text - Falls through to bracketed paste only if clipboard is completely empty (no regression for terminals that do support it) ## Testing - **18 new unit tests** covering clipboard text reading, CRLF normalization, and paste pipeline logic - **Full test suite**: 909 pass, 0 regressions - No changes to image paste behavior - Bracketed paste (`onPaste`) path is fully preserved ## Notes for Reviewers 1. **No regression on macOS/Linux**: The text clipboard read path now runs on all platforms when Ctrl+V is pressed. On macOS/Linux where bracketed paste works, the Ctrl+V handler will read the same text that would have arrived via bracketed paste — the user sees the same result either way. 2. **Image paste preserved**: Image check runs first (unchanged) — only if no image is found does the text path execute. 3. **Manual Windows verification**: To fully validate on Windows 11, run the TUI and press Ctrl+V with text in the clipboard. Verify text appears in the prompt. Test with multiline text (should show `[Pasted ~N lines]` summary). Test with an image in the clipboard (should still paste as image).
yindo added the pull-request label 2026-02-16 18:19:36 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#14851