gemini-cli - 💡(How to fix) Fix [Windows/WSL2] Large paste input causes premature line-break execution before Enter is pressed [3 comments, 1 participants]

Environment

• OS: Windows 11 (host) + WSL2 Ubuntu 24.04
• Terminal: Windows Terminal (also reproduced in PowerShell window)
• Gemini CLI version: v0.39.1 (npm global install in WSL)
• Shell: bash (WSL2)
• Input method: Clipboard paste (Ctrl+V or right-click -> Paste) inside the Gemini CLI interactive prompt

Describe the Bug

When pasting a large block of text (typically multi-line context, code snippets, or a complex task prompt) into the Gemini CLI's interactive input prompt on Windows, the CLI prematurely executes the input as if Enter was pressed, even though the user has not pressed Enter.

This causes the following behavior:

• The first N characters of the pasted content are submitted as a command before the rest of the paste completes
• The remainder of the clipboard content is then injected into the next prompt cycle — corrupting it
• In some cases, newlines embedded in the pasted text trigger mid-paste execution, splitting a single intended prompt into multiple partial, malformed submissions
• The user has no opportunity to review or edit the pasted content before it executes

This makes working with large prompts, code context blocks, or multi-line instructions effectively impossible via paste on Windows.

Steps to Reproduce

1. Open a Windows Terminal window running WSL2 bash
2. Run gemini to open the interactive CLI prompt
3. Copy a block of text to the clipboard that is either:
   • Greater than approximately 500 characters, OR
   • Contains embedded newline characters (\n)
4. Paste using Ctrl+V or right-click -> Paste
5. Observe: The CLI submits partial input before the paste is complete, or submits on the first embedded newline

Expected Behavior

The pasted text should appear in the input buffer without triggering execution. The user should be able to review, edit if needed, and only submit by explicitly pressing Enter.

This is the standard behavior for interactive REPLs and is how claude (Claude Code CLI) handles identical paste operations in the same terminal environment.

Actual Behavior

• Input is prematurely submitted mid-paste
• Terminal output becomes garbled as the remaining clipboard content is injected into a fresh prompt
• Context is lost, requiring the user to manually reassemble and re-enter the prompt

Comparative Baseline

Running Claude Code CLI (claude) in the identical terminal environment (Windows Terminal -> WSL2 -> bash) does not exhibit this behavior. Pasting any amount of text — including multi-line blocks exceeding 2,000 characters — correctly buffers the entire paste before allowing submission.

This confirms the issue is specific to Gemini CLI's input handling, not a Windows Terminal or WSL2 limitation.

Proposed Root Cause

The issue likely originates from how the CLI's readline/input library handles the paste-detection bracket sequence on Windows. On Linux terminals, bracketed paste mode (\e[?2004h) signals to the application that input is a paste event, allowing it to buffer the entire content before processing. It is possible that:

• Gemini CLI does not enable bracketed paste mode in its readline configuration
• Windows Terminal sends newlines as \r\n during paste, which the CLI interprets as Enter keystrokes
• The input handler has a line-length limit that causes early submission

Claude Code CLI appears to handle bracketed paste correctly, making this a solvable problem.

Additional Context

This issue is particularly severe for agentic/autonomous workflows where large amounts of context (code, task descriptions, configuration blocks) need to be passed to the CLI. The inability to reliably paste more than ~1 paragraph of text is a significant UX regression compared to other tools in this space.

Related: #26111 (WSL2 cascade bugs — this issue is additive to that report)