anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Text input goes crazy on scroll #153

New Issue
Open
opened 2026-02-16 17:25:27 -05:00 by yindo · 32 comments
yindo commented 2026-02-16 17:25:27 -05:00
Owner
Copy Link
Copy Source

Originally created by @julionav on GitHub (Jun 19, 2025).

Originally assigned to: @thdxr on GitHub.

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.

https://github.com/user-attachments/assets/8153b8e5-d105-48c3-b1ce-3a5b273afa8f

Originally created by @julionav on GitHub (Jun 19, 2025). Originally assigned to: @thdxr on GitHub. 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. https://github.com/user-attachments/assets/8153b8e5-d105-48c3-b1ce-3a5b273afa8f
yindo commented 2026-02-16 17:25:27 -05:00
Author
Owner
Copy Link
Copy Source

@julionav commented on GitHub (Jun 20, 2025):

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

@julionav commented on GitHub (Jun 20, 2025): Update: only seems to happen on warp.dev -- vscode terminal works fine
yindo commented 2026-02-16 17:25:27 -05:00
Author
Owner
Copy Link
Copy Source

@einarno commented on GitHub (Jun 20, 2025):

Same for me (also warp)

@einarno commented on GitHub (Jun 20, 2025): Same for me (also warp)
yindo commented 2026-02-16 17:25:27 -05:00
Author
Owner
Copy Link
Copy Source

@aashish2057 commented on GitHub (Jun 20, 2025):

btw this happens for me on ghostty

@aashish2057 commented on GitHub (Jun 20, 2025): btw this happens for me on ghostty
yindo commented 2026-02-16 17:25:27 -05:00
Author
Owner
Copy Link
Copy Source

@titan-graham commented on GitHub (Jun 20, 2025):

btw this happens for me on ghostty

@aashish2057

Fixed for me (on Ghostty) in 0.1.114

@titan-graham commented on GitHub (Jun 20, 2025): > btw this happens for me on ghostty @aashish2057 Fixed for me (on Ghostty) in 0.1.114
yindo commented 2026-02-16 17:25:27 -05:00
Author
Owner
Copy Link
Copy Source

@aashish2057 commented on GitHub (Jun 20, 2025):

still having the issue on 0.1.115

@aashish2057 commented on GitHub (Jun 20, 2025): still having the issue on 0.1.115
yindo commented 2026-02-16 17:25:27 -05:00
Author
Owner
Copy Link
Copy Source

@markjaquith commented on GitHub (Jun 21, 2025):

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
@markjaquith commented on GitHub (Jun 21, 2025): 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 ```
yindo commented 2026-02-16 17:25:27 -05:00
Author
Owner
Copy Link
Copy Source

@adamdotdevin commented on GitHub (Jun 23, 2025):

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

@adamdotdevin commented on GitHub (Jun 23, 2025): 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
yindo commented 2026-02-16 17:25:27 -05:00
Author
Owner
Copy Link
Copy Source

@drj613 commented on GitHub (Jun 23, 2025):

This bug also interrupts any currently-running agent processes

@drj613 commented on GitHub (Jun 23, 2025): This bug also interrupts any currently-running agent processes
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@thesobercoder commented on GitHub (Jun 23, 2025):

Same for me.

Image

@thesobercoder commented on GitHub (Jun 23, 2025): Same for me. ![Image](https://github.com/user-attachments/assets/231f806f-95b5-45bb-b30e-7fb912fbcbc3)
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@ahwelgemoed commented on GitHub (Jun 25, 2025):

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.

https://github.com/user-attachments/assets/cf06d532-05e3-409c-9dd5-c0a25f211a7e

@ahwelgemoed commented on GitHub (Jun 25, 2025): 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. https://github.com/user-attachments/assets/cf06d532-05e3-409c-9dd5-c0a25f211a7e
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@marijnbent commented on GitHub (Jun 27, 2025):

Same here. Ghostty.

@marijnbent commented on GitHub (Jun 27, 2025): Same here. Ghostty.
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@mcappelloni commented on GitHub (Jun 28, 2025):

Same for me with ghostty and mac terminal

@mcappelloni commented on GitHub (Jun 28, 2025): Same for me with ghostty and mac terminal
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@adamdotdevin commented on GitHub (Jun 28, 2025):

wanted everyone to know we are looking into this. it's an upstream bug in charm's bubbletea, and we hope to fix the issue there

@adamdotdevin commented on GitHub (Jun 28, 2025): wanted everyone to know we are looking into this. it's an upstream bug in charm's bubbletea, and we hope to fix the issue there
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Jun 28, 2025):

we have a patch for it in 0.1.160 - it's not perfect so let me know if you have issues still

@thdxr commented on GitHub (Jun 28, 2025): we have a patch for it in 0.1.160 - it's not perfect so let me know if you have issues still
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@mcappelloni commented on GitHub (Jun 28, 2025):

version 0.1.161 doesn't seem to have the same issues in ghostty.

@mcappelloni commented on GitHub (Jun 28, 2025): version 0.1.161 doesn't seem to have the same issues in ghostty.
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@cschmatzler commented on GitHub (Jul 2, 2025):

This is still happening on 0.1.176 when scrolling up and then, while the scrolling is happening, scrolling back down.

https://shots.schmatzler.com/DJ0kJhlw

On the latest Ghostty.

@cschmatzler commented on GitHub (Jul 2, 2025): This is still happening on 0.1.176 when scrolling up and then, while the scrolling is happening, scrolling back down. https://shots.schmatzler.com/DJ0kJhlw On the latest Ghostty.
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Jul 2, 2025):

what about v0.1.180

@thdxr commented on GitHub (Jul 2, 2025): what about v0.1.180
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@numisteinn commented on GitHub (Jul 3, 2025):

Still an issue for me in v0.1.181 with iterm on mac

@numisteinn commented on GitHub (Jul 3, 2025): Still an issue for me in v0.1.181 with iterm on mac
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@cschmatzler commented on GitHub (Jul 3, 2025):

Still happening, but the characters it appends to the input field are now just <

Image

@cschmatzler commented on GitHub (Jul 3, 2025): Still happening, but the characters it appends to the input field are now just `<` ![Image](https://github.com/user-attachments/assets/42f1b4cc-3525-4a8e-9ec7-e892a38f9f14)
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@drj613 commented on GitHub (Jul 3, 2025):

The above happened to me my very first time using opencode after the update that fixed it. Haven't had it trigger again though 🤷

0.1.165 on Mac

@drj613 commented on GitHub (Jul 3, 2025): The above happened to me my very first time using opencode after the update that fixed it. Haven't had it trigger again though 🤷 0.1.165 on Mac
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@MichaelVessia commented on GitHub (Jul 3, 2025):

Not sure if this is helpful or piling on, but still seeing this on 0.1.189. Macos w/ ghostty. The people yearn for opentui.

Image

@MichaelVessia commented on GitHub (Jul 3, 2025): Not sure if this is helpful or piling on, but still seeing this on 0.1.189. Macos w/ ghostty. The people yearn for opentui. ![Image](https://github.com/user-attachments/assets/ca47f87d-c4bd-47a8-9607-469be3489169)
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@cschmatzler commented on GitHub (Jul 12, 2025):

@adamdotdevin I know you pushed a few more commits regarding this, including 22b244f847, but it's still a thing on 0.2.33

Image
@cschmatzler commented on GitHub (Jul 12, 2025): @adamdotdevin I know you pushed a few more commits regarding this, including 22b244f847d62a2e3a73db54db25eeb8646df410, but it's still a thing on 0.2.33 <img width="1382" height="310" alt="Image" src="https://github.com/user-attachments/assets/3a6266dd-f266-4bb8-844e-2d0af4b838f7" />
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@kksimons commented on GitHub (Aug 4, 2025):

This fix works for me if other people want to test it out locally to confirm: fix: input bleed with mouse scrolling for Ghostty on macOS

@kksimons commented on GitHub (Aug 4, 2025): This fix works for me if other people want to test it out locally to confirm: [fix: input bleed with mouse scrolling for Ghostty on macOS](https://github.com/sst/opencode/pull/1572/commits/ed8c9054c9b1eae0be0aec4b10fa80791a202d9b)
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@arash-qc commented on GitHub (Aug 31, 2025):

FUCK BUBBLE TEA

@arash-qc commented on GitHub (Aug 31, 2025): FUCK BUBBLE TEA
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@psugihara commented on GitHub (Sep 10, 2025):

happens to me in Terminal.app

Image

first time using opencode today btw. very nice work other than this bug!

@psugihara commented on GitHub (Sep 10, 2025): happens to me in Terminal.app <img width="453" height="77" alt="Image" src="https://github.com/user-attachments/assets/71bcd9b6-b0bc-457d-9c74-416d4135eda6" /> first time using opencode today btw. very nice work other than this bug!
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@zenyr commented on GitHub (Sep 24, 2025):

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.

@zenyr commented on GitHub (Sep 24, 2025): 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.
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@stabildev commented on GitHub (Sep 24, 2025):

same, just experienced this in Ghostty + v0.11.3

Image
@stabildev commented on GitHub (Sep 24, 2025): same, just experienced this in Ghostty + `v0.11.3` <img width="1706" height="133" alt="Image" src="https://github.com/user-attachments/assets/79e1a29c-3f26-4fcd-b3bd-eb91b28ec14c" />
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Sep 24, 2025):

I think this will be fixed as part of opentui migration

@rekram1-node commented on GitHub (Sep 24, 2025): I think this will be fixed as part of opentui migration
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@kud commented on GitHub (Sep 30, 2025):

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.

@kud commented on GitHub (Sep 30, 2025): 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.
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@Souhib commented on GitHub (Oct 4, 2025):

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

@Souhib commented on GitHub (Oct 4, 2025): > 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
yindo commented 2026-02-16 17:25:28 -05:00
Author
Owner
Copy Link
Copy Source

@kud commented on GitHub (Oct 5, 2025):

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).

@kud commented on GitHub (Oct 5, 2025): 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).
yindo commented 2026-02-16 17:25:29 -05:00
Author
Owner
Copy Link
Copy Source

@michaelgodshall commented on GitHub (Oct 30, 2025):

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.
Image
@michaelgodshall commented on GitHub (Oct 30, 2025): 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. <img width="1073" height="107" alt="Image" src="https://github.com/user-attachments/assets/7a2d4539-8866-478e-b1c1-a36d47c4aea4" />
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#153
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?