Copy on Windows inside WSL when using Grok Build not working

[cristianuibar]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

While using Grok build inside of WSL on Windows on Ubuntu, when I select some text, I cannot copy it, even though it says "copied". I assume this is because Grok build is using Vim key bindings, maybe, and it is automatically deselecting my selection, so I cannot even press Ctrl+Shift+C to copy.

To reproduce

Open Grok build inside of WSL on Windows and try to copy some text.

Expected behavior

No response

Screenshots, videos, and logs

No response

Operating system (OS)

Windows

Operating system and version

25H2

Shell Version

5.2.21(1)-release (x86_64-pc-linux-gnu)

Current Warp version

v0.2026.05.13.09.15.stable_03

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@cristianuibar

Here's what I found while triaging this issue:

This looks like it may involve full-screen app mouse handling rather than the Windows clipboard itself. As a temporary workaround, please try holding Shift while dragging to select text in Grok Build; Warp's full-screen terminal path treats Shift-drag as Warp-side selection even when the app is using mouse reporting.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a short screen recording showing the selection, the “copied” indication, and what gets pasted immediately afterward?
2. In the same Grok Build screen, does holding Shift while dragging to select text make Ctrl+Shift+C copy the selected text correctly?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that copying selected text in Grok Build on Windows WSL likely fails because the full-screen TUI is receiving mouse events through terminal mouse reporting instead of leaving a Warp-owned text selection to copy..

Initial triage

This appears to be a Windows/WSL terminal-selection bug triggered inside a full-screen or mouse-aware TUI, rather than a generic Windows clipboard failure. Grok Build likely enables SGR mouse reporting, and Warp's alt-screen mouse path forwards drag/release events to the application unless Shift is held or terminal mouse reporting is disabled.

Relevant code paths:

• app/src/terminal/alt_screen/mod.rs decides whether Warp intercepts mouse events or forwards them to the terminal app.
• app/src/terminal/alt_screen/alt_screen_element.rs begins Warp-side alt-screen selection only when mouse events are intercepted; otherwise it sends mouse events to the PTY.
• app/src/terminal/view.rs copies only from Warp-owned selections, selected input text, CLI subagent selections, or selected blocks.
• crates/warpui/src/windowing/winit/windows/clipboard.rs handles Windows clipboard writes, but there is no evidence yet that the clipboard write itself is failing.

Duplicate check: I enumerated open non-PR issues and recently closed issues. There are related copy/keybinding reports (#6045, #4604, #3558), but I did not find two matching duplicates for the specific Windows + WSL + Grok Build selection/copy failure.

Follow-up from the reporter should confirm whether this is the mouse-reporting path and provide visual evidence of exactly what selection remains when Copy is invoked.

Question reasoning

1. Can you attach a short screen recording showing the selection, the “copied” indication, and what gets pasted immediately afterward? — The symptom is visual and selection-state dependent; a recording would show whether the selection is Warp-owned, app-owned, or being cleared before the copy action runs.
2. In the same Grok Build screen, does holding Shift while dragging to select text make Ctrl+Shift+C copy the selected text correctly? — Warp's alt-screen code forces Warp-side selection when Shift is held, so this directly tests whether terminal mouse reporting is the cause.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[cristianuibar]

Hey @oz-agent, your assessment is right.

I can select text if I am holding SHIFT while mouse dragging and then CTRL+SHIFT+C to copy! That's great news! Thank you.

1. When I simply select using my mouse some text inside of Grok build, it will deselect automatically and show inside of Grok build on the right bottom side a copied message. This makes me believe that the clipboard or my selection was copied, but in fact it was not or it's not available for me.

2. Yes, holding Shift keeps the selection active after I release the click, and after I'm using Control+Shift+C, it works normally. The workaround is to hold Shift while selecting.

However, I would expect that this should work by default when using Grok build, so perhaps full support for Grok build is not yet available inside of Warp, especially on Windows and WSL.

[oz-for-oss]

@cristianuibar

Thanks for confirming. That behavior matches Warp's current mouse-reporting model: when a full-screen/TUI app such as Grok Build enables mouse reporting, a plain mouse drag is sent to the app, so Warp does not own a native selection for Ctrl+Shift+C to copy. Holding Shift while dragging is the supported way to force Warp-native selection without disabling mouse reporting.

The "copied" message is most likely coming from Grok Build's own mouse/selection handling rather than from Warp's native selection. If Grok Build still works acceptably without mouse interactions, another workaround is to turn off Enable Mouse Reporting in Settings > Features > Terminal; otherwise, Shift+drag is the safest workaround for now.

I agree this is a reasonable compatibility gap for Grok Build on Windows/WSL: users expect selected text to be copyable by default, but Warp currently prioritizes forwarding bare mouse gestures to mouse-reporting terminal apps.

Reasoning

Chose response mode because issue #11096 is already triaged and the explicit @oz-agent comment is a reporter follow-up confirming that Shift-drag works and asking whether default Grok Build behavior should be supported. The workflow should not mutate labels in response mode.

Code inspection supports the explanation. app/src/terminal/alt_screen/mod.rs:10-29 implements should_intercept_mouse: it always intercepts when shift is held, but when SGR mouse mode plus mouse tracking are active and terminal.mouse_reporting_enabled is true, it returns false so Warp does not intercept. app/src/terminal/alt_screen/alt_screen_element.rs:263-279 dispatches TerminalAction::AltSelect(SelectAction::Begin) only when should_intercept_mouse is true; otherwise it clears Warp alt selection and dispatches TerminalAction::AltMouseAction to the running app. The corresponding drag/up paths in app/src/terminal/alt_screen/alt_screen_element.rs:390-441 continue forwarding mouse events when not intercepted. The block-list path for an active long-running block follows the same pattern in app/src/terminal/block_list_element.rs:1580-1611 and app/src/terminal/block_list_element.rs:1996-2011.

Documentation matches this model: docs/src/content/docs/terminal/more-features/full-screen-apps.mdx:9-24 says mouse events can be sent to the running app or handled by Warp, and that holding SHIFT sends a mouse event to Warp for text selection without disabling mouse reporting. The settings surface is in app/src/settings_view/features_page.rs:6409-6467, and the setting is defined as terminal.mouse_reporting_enabled in app/src/terminal/alt_screen_reporting.rs:5-14.

The reported Grok Build toast is likely app-owned because Warp's native clipboard path for terminal apps is different: OSC 52 sequences are decoded in app/src/terminal/model/grid/ansi_handler.rs:1164-1177, converted to ModelEvent::ClipboardStore in app/src/terminal/model_events.rs:236-241, and written to the platform clipboard in app/src/terminal/view.rs:10849-10852. A plain mouse drag forwarded to Grok Build does not create Warp-native selected text for Ctrl+Shift+C; Grok Build would need to either emit clipboard content itself or the user must force Warp selection with Shift-drag/disable mouse reporting.

Duplicate check: enumerated all open non-PR issues via gh api --paginate 'repos/warpdotdev/warp/issues?state=open&per_page=100' and also checked issues closed since 2026-05-09. Related but non-identical issues found: #10353 requests an opt-in native left-drag selection setting for mouse-reporting TUIs, #9994 was a recent Windows text-selection auto-deselect issue tied to soft-wrapped glyph indices and PR #10445, and #10559 covered transient Windows remote tmux clipboard failure. None provide two likely duplicate candidates for this exact Windows/WSL/Grok Build copy-selection behavior under the dedupe skill threshold.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz