You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Mouse selection is very unreliable and drives me nuts (vscode terminal) #15760
I'm not sure exactly when this started, but it feels like it used to work better a month or two ago. When I click and drag to select text in the opencode cli output, most of the time it fails to register which results in no drag selection. So I have to do it again, and again, and again. Drives me totally bananas!
This bug happens in vscode terminal (where I like to use terminals), and when I test in iterm2 mouse selection works normally (I tried clicking a bunch back and forth between two splits in iterm2 and I couldn't get the bug to happen even once). Here's a screen recording in vscode terminal showing the bug:
I see that happen as well in Ghostty, so it might not be terminal specific and I am sure it was better at some point. I tried to reproduce the issue with tests, but didn't succeed. I need to track this down.
@kommander I narrowed down my repro: It doesn't happen in opencode 1.1.59 (Feb 11) but does happen in opencode 1.1.60 (Feb 12). That implicates one of the changes in opentui 0.1.77 → 0.1.79:
Fwiw, in my opus-4.6 chat above it claims "VSCode terminal batches multiple mouse escape sequences into a single stdin read", in case that's a helpful lead on why this happens in vscode terminal and ghostty but not iterm2.
Will have a closer look and get it fixed. Then selection should actually work just properly in vscode, as far as I could test at least.
I think its because a chunk like \x1b[I\x1b[<0;10;5M (focus-in + mouse down) results in zero parsed mouse events right now with broken up input parsing
Did you also experience strange selection behavior outside of vscode? because I have! Fe in the dev tools of Firefox and Safari, can not copy out of the console, and rarely also in other places, it might just be different problems with other software, but somehow this whole thing is quite fishy.
I have the strong feeling someone is doing this on purpose to force you to use another operating system. Vs code devs seem all to use windows, people reporting issues since 2019, it was never fixed... But they say it works better now on Windows!
And fuck this behavior reminds me just to much of the times when your Windows 95 has been totally hacked down once again. Then it also used to behave like that!!
Activity
github-actions commentedon Mar 2, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct from the above, please add a comment explaining how it differs so maintainers can keep both open.
kommander commentedon Mar 2, 2026
I see that happen as well in Ghostty, so it might not be terminal specific and I am sure it was better at some point. I tried to reproduce the issue with tests, but didn't succeed. I need to track this down.
simonklee commentedon Mar 2, 2026
Independent of terminal, it also matters where you start the selection. I'm not saying this is the only issue - but it's one issue.
select.mp4
jdanbrown commentedon Mar 2, 2026
@kommander I narrowed down my repro: It doesn't happen in opencode 1.1.59 (Feb 11) but does happen in opencode 1.1.60 (Feb 12). That implicates one of the changes in opentui 0.1.77 → 0.1.79:
Here's the opus-4.6 chat that searched through the opentui commits to find this:
jdanbrown commentedon Mar 2, 2026
Fwiw, in my opus-4.6 chat above it claims "VSCode terminal batches multiple mouse escape sequences into a single stdin read", in case that's a helpful lead on why this happens in vscode terminal and ghostty but not iterm2.
kommander commentedon Mar 2, 2026
I've identified the exact commit in opentui: anomalyco/opentui@f91df10#diff-b67baa356adfb0988914fac554870cbf24924353189eb32933b549b9da71f478
Will have a closer look and get it fixed. Then selection should actually work just properly in vscode, as far as I could test at least.
simonklee commentedon Mar 3, 2026
I think its because a chunk like
\x1b[I\x1b[<0;10;5M(focus-in + mouse down) results in zero parsed mouse events right now with broken up input parsingonly restore terminal modes on focus when blurred previously (#772)
jdanbrown commentedon Mar 3, 2026
Thank you! This appears to be working better now in 1.2.16.
damianhunziker commentedon Jul 26, 2026
Did you also experience strange selection behavior outside of vscode? because I have! Fe in the dev tools of Firefox and Safari, can not copy out of the console, and rarely also in other places, it might just be different problems with other software, but somehow this whole thing is quite fishy.
I have the strong feeling someone is doing this on purpose to force you to use another operating system. Vs code devs seem all to use windows, people reporting issues since 2019, it was never fixed... But they say it works better now on Windows!
And fuck this behavior reminds me just to much of the times when your Windows 95 has been totally hacked down once again. Then it also used to behave like that!!