Text input goes crazy on scroll

Ummmm. Hard to explain, but If I scroll very fast with my MX Master 2S (you spin the wheel and it continues spinning), the input goes crazy with some weird input. If is do it without letting it spin on its own, in a controlled way, it doesnt happen.

CleanShot.2025-06-19.at.19.55.06.mp4

Update: only seems to happen on warp.dev -- vscode terminal works fine

Same for me (also warp)

btw this happens for me on ghostty

@aashish2057

btw this happens for me on ghostty

@aashish2057

Fixed for me (on Ghostty) in 0.1.114

still having the issue on 0.1.115

Happens for me with two-finger trackpad side-scrolling.

macOS
OpenCode 0.1.117
Ghostty
tmux

It inputs stuff like this:

;29M;143;29M[<67;143;29M29M143;29M[<67;143;29M9M43;29M67;143;29MM3;29
                                                                                  M7;143;29M;29M;150;29M[<66;150;29M29M150;29M[<66;150;29M9M50;29M66;15
                                                                                  0;29MM;41M;101;41M[<67;101;41M41M101;41M[<67;101;41M1M01;41M67;101;41
                                                                                  M

so it looks like bubbletea emits keypress messages for some mouse wheel events on some setups (or maybe even specific to some mice). i'll let the charm team know, if anyone wants to do some spelunking upstream that'd be super helpful

This bug also interrupts any currently-running agent processes

Same for me.

I can reliably recreate the issue on Kitty and Macs built in terminal.

It happens on any scroll, but it only happens if I "fast" scroll or "throw" the scroll. Not sure how to best describe it.
Happens on touchpad and MX Master 3 "throw" scrolling.

trow.mp4

Same here. Ghostty.

Same for me with ghostty and mac terminal

Still a thing for me: opencode v0.11.3 + Ghostty. Slowly scrolling screen works fine but if I scroll up or down too fast it starts recording certain ansi sequences as described above.

same, just experienced this in Ghostty + v0.11.3

I think this will be fixed as part of opentui migration

I have a similar issue with iTerm2. It's not exactly the same as what you guys are experiencing, but when I scroll, it scrolls in the input instead of the result window. So, it actually scrolls the prompt history instead of the window.

I have a similar issue with iTerm2. It's not exactly the same as what you guys are experiencing, but when I scroll, it scrolls in the input instead of the result window. So, it actually scrolls the prompt history instead of the window.

Having the same problem here, on iTerm2 also

I start to understand. On certain cases, iterm2 starts to use "alternative scroll" which is actually arrow up/down. But it's due to opencode more than iterm2. It happens when the classic scroll is broken. Because if I disable the alternative scroll, nothing works anymore in this case.

From my investigation with ChatGPT:

It seems this behaviour is caused by how opencode interacts with iTerm2’s “alternate scroll mode”.

When opencode switches into the alternate screen (via DECSET 1049) and enables mouse reporting (DECSET 1000/1002/1006), iTerm2 interprets this as a signal to stop normal scrollback and instead handle scroll events differently. If “Scroll wheel sends arrow keys when in alternate screen mode” is enabled in iTerm2, the terminal converts wheel input into Up/Down arrow keys.

The issue appears when opencode’s own scroll handling isn’t active or fails to consume these wheel events properly. In that case, iTerm2 still sends the arrow key events, which end up being interpreted by the shell history or text input instead of scrolling the window content.

If we disable “Alternate Mouse Scroll” in iTerm2, then scrolling doesn’t work at all in those situations — meaning opencode isn’t processing the wheel events directly, and iTerm2’s fallback is the only thing keeping it functional.

So in short:

iTerm2 changes behaviour when an app enables mouse reporting.

opencode seems to enable it but not handle the wheel events consistently.

When that happens, iTerm2 falls back to sending arrow keys, which explains why the history starts moving instead of the UI.

Ideally, opencode should only enable mouse reporting when it can actually process mouse or wheel input, or disable it when focus is on a non-scrollable area (like an input field).

I just started using opencode (v0.15.26) yesterday with Ghostty (v1.2.3) and I'm seeing the same issue others have been reporting in this thread (see screenshot).

Here are some observations:

So far scrolling works fine early on in a chat session. I've only seen this issue in long running conversations, especially after long responses from the agent (I'm using Sonnet 4.5) where long scrolling is necessary.
It only seems to happen when I'm doing long scroll movements. Short scroll movements don't seem to trigger it.

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

Merge pull request anomalyco#220 from shimo4228/feat/skills/swift-pro…

fix: dedupe artifacts by full path (anomalyco#220)

docs(web): relink two shipped docs pages within the docs bundle, not …

fix: derive user-facing docs links from the live instance, else drop …

Navigation Menu

Repository navigation

Text input goes crazy on scroll #220

18 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Text input goes crazy on scroll #220

Description

Activity

julionav commented on Jun 20, 2025

einarno commented on Jun 20, 2025

aashish2057 commented on Jun 20, 2025

titan-graham commented on Jun 20, 2025

aashish2057 commented on Jun 20, 2025

markjaquith commented on Jun 21, 2025

adamdotdevin commented on Jun 23, 2025

drj613 commented on Jun 23, 2025

thesobercoder commented on Jun 23, 2025

ahwelgemoed commented on Jun 25, 2025

marijnbent commented on Jun 27, 2025

mcappelloni commented on Jun 28, 2025

18 remaining items

zenyr commented on Sep 24, 2025

henrikklee commented on Sep 24, 2025

rekram1-node commented on Sep 24, 2025

kud commented on Sep 30, 2025

Souhib commented on Oct 4, 2025

kud commented on Oct 5, 2025

michaelgodshall commented on Oct 30, 2025

thdxr commented on Mar 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions