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
tui.json "mouse": false causes mouse wheel to fall back to arrow keys, triggering prompt-history navigation instead of scrolling the message viewport #35295
When I set "mouse": false in tui.json (intending to fully disable mouse input in the TUI), the mouse wheel does NOT scroll the visible message viewport — the chat area that shows all past messages, both my prompts and the agent's responses.
Instead, mouse-wheel events fall back to arrow-key events inside the prompt editor, which cycles through my previously-sent prompts (the prompt-history list). So mouse: false effectively turns "scroll chat" into "navigate my old prompts", which is the opposite of what I expected.
This means that with mouse: false, there is no way at all to scroll the chat viewport using the mouse — and using the wheel accidentally cycles my prompt history.
Plugins
none
OpenCode version
v1.17.13
Steps to reproduce
Start a session with enough messages to exceed the viewport height (so scrolling is actually needed to see earlier messages).
Put this in ~/.config/opencode/tui.json:
{
"mouse": false
}
Launch opencode.
Make sure the prompt input has focus (no popup / autocomplete open).
Scroll the mouse wheel up and down.
Screenshot and/or share link
N/A
Operating System
Debian 13
Terminal
zsh
Additional Context
It looks like the implementation falls back to converting mouse-wheel events into Up/Down arrow-key events when mouse: false. Those arrow keys then reach the prompt editor, where they navigate prompt-history rather than scrolling the chat viewport.
I would expect one of:
mouse: false → wheel events are fully ignored (so there's no accidental prompt-history navigation, even if it means the chat viewport can't be scrolled with the mouse while disabled), or
mouse: false → wheel still scrolls the chat viewport (only click / select is disabled).
Either way, "wheel = arrow key = prompt history navigation" is not desirable.
I started to have the silly scroll up in the prompt versus window as of 1.17.x, but disabling mouse and auto scroll has no effect when placed in user or project config files (opencode.jason nor tui.json). I am using 1.18.4 and the issue persists. Quite infuriating for the mouse behaved as expected prior to whatever change was made in 1.17.x.
Anyone found a solution for this? It is driving me absolutely f'ing nuts.
On resolving my issue, it does not appear to be the same as the original post. Apologies.
Updating my terminal configuration, $HOME/.config/foot/foot.ini, fixed the issue for me.
On researching, I found references to the feature and default value as far back as 2022, so the feature is unlikely to be the root cause. It does, however, fix the problem.
Hopefully, other foot users will benefit.
# default value is 'yes' but breaks opencode v1.17.3+ mouse handling.
alternate-scroll-mode=no
Activity
jiexray commentedon Jul 6, 2026
hi, I also met this problem with OpenCode 1.17.13. I have setup this in
~/.config/opencode/opencode.json, but nothing works.rharmonson commentedon Jul 20, 2026
I started to have the silly scroll up in the prompt versus window as of 1.17.x, but disabling mouse and auto scroll has no effect when placed in user or project config files (opencode.jason nor tui.json). I am using 1.18.4 and the issue persists. Quite infuriating for the mouse behaved as expected prior to whatever change was made in 1.17.x.
rharmonson commentedon Aug 2, 2026
Anyone found a solution for this? It is driving me absolutely f'ing nuts.
rharmonson commentedon Aug 15, 2026
On resolving my issue, it does not appear to be the same as the original post. Apologies.
Updating my terminal configuration,
$HOME/.config/foot/foot.ini, fixed the issue for me.On researching, I found references to the feature and default value as far back as 2022, so the feature is unlikely to be the root cause. It does, however, fix the problem.
Hopefully, other foot users will benefit.
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊