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
[FEATURE]: More control over mouse capture in TUI #43676
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
The current setting for mouse capture in TUI is to either have it enabled, or fully disable it.
I would like a more granular control over which features of the mouse capture I want to use.
For instance, instead of :
{
..."mouse": true, // or "mouse": false
}
I would like to be able to write :
{
..."mouse": {
"scroll": true, // I want to use the mouse scrolling normally"select": false, // I DONT want opencode to override my terminal's select behavior, I have it customized how I like it (lots of users seem to complain of related selection issues)"click": true, // I want to use the click features to toggle subagents / thinking blocks / tool blocks"move_cursor_on_click": false// I DONT want opencode to move the cursor when I click around my text prompt
}
Theses are the options I would personally need (and I'm sure a lot of people would like similar options) but I would not be opposed to have access to even more control if it makes sense.
Mouse capture is a pretty useful but invasive feature, which means that its difficult to live without it but it has a lot of drawbacks. In order to properly balance theses 2 aspects of it, users need as much control as possible over it.
For backward compatibility, "mouse": true or "mouse": false would just enable or disable every mouse feature as it currently does.
Reacted by Niels Bach-Sørensen, Matthias and Barry Moore II
Supporting this. Claude Code already solves exactly this: CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 (v2.1.195+) disables click/drag/hover while keeping wheel scrolling. A similar granular split here (e.g. mouse.click: false while mouse: true keeps wheel scroll) would cover this use case.
Thanks for the detailed request! You're asking to replace the on/off mouse setting in the TUI with separate options for scrolling, text selection, clicking blocks (subagents, thinking, tools) and moving the prompt cursor on click. true and false would still turn everything on or off, as they do now.
Maintainers will consider it. One note: terminals capture the mouse all-or-nothing, so while capture is on, drag-selection always goes to the app. In most terminals, holding Shift (or Option on macOS) while dragging still gives you the terminal's own selection, which may help in the meantime.
On move_cursor_on_click: I've built this for the prompt and use it daily: axeluhl@e0f97ff
Selecting with the mouse (drag, double or triple click) leaves the cursor where it is.
Typing or pasting afterwards acts at the cursor and drops the selection instead of replacing it.
A single click still places the cursor, after the double-click interval, so a double click never moves it first. A key press ends the wait early.
Right now it's on when terminal.copy is primary or both (from #32370), where a selection is mostly meant for middle-click paste. It could just as well be a mouse sub-setting as proposed here. Happy to turn it into a PR once there's a direction.
Activity
github-actions commentedon Aug 20, 2026
This issue might be a duplicate of existing issues. Please check:
fmichaut-diff commentedon Aug 20, 2026
Not a duplicate. There is overlap, but this feature request is to address even more usecases than the very specific ones linked above
gh-nbs commentedon Sep 2, 2026
Supporting this. Claude Code already solves exactly this:
CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1(v2.1.195+) disables click/drag/hover while keeping wheel scrolling. A similar granular split here (e.g.mouse.click: falsewhilemouse: truekeeps wheel scroll) would cover this use case.opencodejr commentedon Oct 28, 2026
Thanks for the detailed request! You're asking to replace the on/off
mousesetting in the TUI with separate options for scrolling, text selection, clicking blocks (subagents, thinking, tools) and moving the prompt cursor on click.trueandfalsewould still turn everything on or off, as they do now.Maintainers will consider it. One note: terminals capture the mouse all-or-nothing, so while capture is on, drag-selection always goes to the app. In most terminals, holding Shift (or Option on macOS) while dragging still gives you the terminal's own selection, which may help in the meantime.
Related issues:
mouseoptionaxeluhl commentedon Oct 30, 2026
On
move_cursor_on_click: I've built this for the prompt and use it daily: axeluhl@e0f97ffRight now it's on when
terminal.copyisprimaryorboth(from #32370), where a selection is mostly meant for middle-click paste. It could just as well be amousesub-setting as proposed here. Happy to turn it into a PR once there's a direction.