Repository navigation
tui: drag-selection freezes the interface when mouse capture is enabled #51056
Description
Summary
Drag-selecting text with the mouse while mouse capture is enabled (the default) freezes the TUI: rendering stops, typed input stops being displayed, and left clicks stop responding. The process stays alive and still accepts keystrokes, so the only recovery is exiting and reopening the interface.
This looks like the same symptom that PR #44430 aimed to fix ("rapid mouse-selection freeze"), which was closed on 2026-09-19 without being merged.
Environment
- opencode version: 2.0.15
- OS: Linux deepin 6.18.48-amd64-desktop-rolling fix: Show correct file paths in permission window #25.01.01.35 SMP PREEMPT_DYNAMIC Mon Aug 31 10:31:28 CST 2026 x86_64 GNU/Linux (Deepin 25, Debian-based)
- Terminal: Deepin Terminal 6.5.40 (VTE-based);
TERM=xterm-256color,COLORTERM=truecolor,XDG_SESSION_TYPE=x11 - Shell: /bin/bash
- Install/channel: latest — official binary at
~/.opencode/bin/opencode, auto-update enabled - Active plugins: none (two v1-format plugins were configured earlier and failed to load; both have since been removed)
Reproduction
- Start opencode in Deepin Terminal with the default configuration (mouse capture enabled).
- Wait for the TUI to finish rendering — it does not matter whether the session is idle or streaming.
- Press the left mouse button inside the transcript and drag to select text (the select-to-copy interaction).
- Observe the interface.
Expected Behavior
The dragged range highlights and is copied, and the TUI keeps rendering and stays fully interactive.
Actual Behavior
The interface freezes at the drag:
- The screen stops repainting entirely
- Characters typed into the prompt are still accepted, but nothing is drawn
- Left mouse clicks produce no reaction
- Nothing is written to
~/.local/share/opencode/log/opencode.logat the moment of the freeze - Recovering requires Ctrl+C and reopening; no session data is lost, since the TUI is only a client
Frequency: consistently reproducible on this machine — every drag-selection attempt while mouse capture is enabled.
Additional Context
Related history
- Mouse selection is very unreliable and drives me nuts (vscode terminal) #15760 "Mouse selection is very unreliable and drives me nuts" (+ duplicate Cannot select text in chat messages - mouse capture stuck in prompt field ( VSCode terminal) #15212) covered the selection fails to register symptom and was fixed in v1.2.16 by @kommander via opentui commit
f91df10. This report describes a different symptom: selection starts, but the UI then locks up. - PR fix(tui): coalesce rapid selection copies #44430
fix(tui): coalesce rapid selection copiestargets exactly this freeze ("the original rapid mouse-selection freeze") and was requested by a team member via Slack. It was closed without merging, so the fix has not landed. - fix(tui): coalesce rapid selection copies #44430's diagnosis matches what I see: selection-triggered clipboard writes pile up in OpenTUI's serialized native clipboard queue and starve the render path.
Linux/VTE data point
Public reports so far concentrate on Windows, macOS, Ghostty, iTerm2, and the VS Code terminal, and #44430's pending validation targeted Windows/PowerShell. This report adds a Linux + X11 + VTE confirmation — worth checking whether #44430 also resolves it here.
Workarounds that do avoid the freeze
- Hold Shift while drag-selecting. The terminal performs selection natively, the drag events never reach the app, and the TUI stays completely responsive. This is what I now use.
- Disable mouse capture in
~/.config/opencode/cli.jsonwith"mouse": false. Native selection is restored, but UI elements can then only be driven from the keyboard — note the "Getting started" card's close button is bound toonMouseUponly and has no keyboard equivalent.
Separate observation (possibly its own issue)
With mouse capture disabled, Deepin Terminal (VTE) translates the mouse wheel into ↑/↓ key presses inside the alternate screen, so scrolling the wheel navigates prompt history instead of scrolling the transcript. Report #49622 covers a wheel-capture failure in iTerm2 on macOS and may be adjacent.
Happy to run additional diagnostics or test a build with #44430 re-applied.
Activity
lipido commentedon Oct 16, 2026
I confirm this issue
opencodejr commentedon Oct 28, 2026
Thanks for the detailed report and the workarounds.
I tried to reproduce this on opencode 2.0.15 with the default config (mouse capture and copy-on-select on) in our headless test terminal. I drag-selected text in an assistant reply, first a few times and then 40 times in quick succession, and then typed into the prompt. Each time the selection highlighted, "Copied to clipboard" appeared, and the interface kept repainting normally.
Our test setup isn't a real VTE terminal on an X11 desktop, though, and its copy never reached a real system clipboard. That clipboard step (or how VTE handles the terminal's copy request) is probably where the freeze happens, so a maintainer with a Linux/X11 VTE setup will need to look at it.
If you have a moment, these would help narrow it down:
"terminal": { "copy": "manual" }in~/.config/opencode/cli.json? That keeps mouse capture but skips the copy on release, so drags no longer write to the clipboard.xclip,xselorwl-copyare installed? Does it still freeze if you run opencode in a different terminal on the same machine, for example GNOME Terminal (also VTE) or a non-VTE one such as Alacritty, kitty or xterm?Related: PR #44430 (closed without merging) tried to fix a selection freeze by merging rapid clipboard writes into one.
lipido commentedon Nov 5, 2026
I have this issue and tried:
The freeze is often after the second copy attempt. The first copy works, the second freezes.
My desktop is Ubuntu 22.04. Tried two terminals (yakuake and konsole) and I get the same behaviour. In a different desktop with the same setup, I got the same, but in a third desktop with Ubuntu 24.04, the bug does not arise.
jianhope commentedon Nov 11, 2026
Still reproducible on the latest release, with a config bisect that pinpoints the trigger.
Environment
@opencode/[email protected])TERM=xterm-256color,COLORTERM=truecolor, X11Reproduction
cli.json(mouse: true,terminal.copy: "select").Actual Behavior
The prompt input stops accepting keyboard input, and clicking the input box does not restore it. The interface appears frozen for input purposes until the TUI is restarted. Reproduces consistently. Same symptom class as the unmerged PR #44430.
Key finding (config bisect)
Setting
terminal.copytomanualin~/.config/opencode/cli.jsoneliminates the problem completely — drag-selection works, and the prompt never gets stuck:{ "mouse": true, "terminal": { "copy": "manual" } } So the freeze is triggered by the auto-copy-on-select path (terminal.copy: "select" is the default), not by mouse capture itself. Hopefully that helps narrow down the fix.