[Bug] TUI movement too fast on MacBook TouchBar causing rapid screen scrolling

Bug Description

The OpenCode TUI interface moves/scrolls too quickly when interacting with it on MacBook devices, particularly when using the TouchBar. This causes the interface to rapidly scroll through content, making it difficult to navigate and read the output effectively.

Expected Behavior

TUI should scroll at a reasonable, controllable speed
Users should be able to navigate through the interface smoothly
TouchBar interactions should provide precise control over scrolling

Actual Behavior

TUI scrolls extremely fast through content
Makes it nearly impossible to read or interact with the interface effectively
TouchBar seems to trigger rapid, uncontrollable scrolling

Comparison with Other Tools

Important: This issue is specific to OpenCode. Other similar tools work correctly:

Claude Code scrolling works perfectly with TouchBar - no speed issues
Files in Cursor IDE scroll at normal, expected speeds with TouchBar
This suggests the issue is specific to OpenCode's TUI implementation

Environment

Platform: macOS
Device: MacBook with TouchBar
**OpenCode Version: 0.11.3
Terminal: Cursor IDE

Steps to Reproduce

Launch OpenCode in terminal
Interact with the TUI using TouchBar or trackpad scrolling
Observe rapid, uncontrollable scrolling behavior
Compare with Claude Code or Cursor IDE for reference

Additional Context

This issue specifically affects the usability of OpenCode on MacBook devices with TouchBar functionality. The scroll sensitivity appears to be too high for the TouchBar's input characteristics.

**Video demonstration provided"

Possible Solutions

Add scroll sensitivity configuration options
Implement scroll speed dampening for TouchBar devices
Add scroll acceleration/deceleration curves similar to other macOS applications
Study how Claude Code handles TouchBar scrolling for reference

This issue might be a duplicate of existing issues. Please check:

Opencode freezes when pressing option + left arrow key on MacBook with high CPU usage #2688: OpenCode freezes when pressing option + left arrow key on MacBook with high CPU usage - also specifically affects MacBook users with navigation/input issues
Windows WSL/Jetbrains Goland scrolling bug #2548: Windows WSL/Jetbrains GoLand scrolling bug - describes similar rapid scrolling behavior where scroll input gets stuck and causes uncontrollable scrolling
When scrolling up the output text went behind other ui elements. #2613: When scrolling up the output text went behind other UI elements - related to scrolling behavior issues in the TUI

Feel free to ignore if none of these address your specific case.

@mahidalhan

@mahidalhan the scroll speed is pretty dependent on your emulator right now, if it is too fast consider putting this in your opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "tui": {
    "scroll_speed": 1,
  },
}

issue-opencode-lean.mp4

@mahidalhan

@mahidalhan yeah our scroll is pretty poor, luckily the tui is currently being rewritten and problems like this and many others should be addressed either by the migration or hopefully swiftly after.

Scroll speed issues have been raised for a while so I hope they get taken care of by migration.

I'm running the latest version of OpenCode and the crazy scroll speed still affects OpenCode when it's running inside Zed IDE terminal (not via the Zed AI panel), too, on any Macbook that I've used. Adjusting the scroll spead in opencode.json has no meaningful effect.

This is completely broken, does anyone have a fix, it makes the tool pretty much unusable.

@felixmccuaig

@felixmccuaig what terminal are u using?

@rekram1-node

@rekram1-node this is the terminal in VS Code. While in iTerm2 the scroll speed is reasonable in VS Code it is insanely fast and scroll_speed no longer makes a difference. scroll_speed = 1 used to work pre-v1 to fix it in VS Code.

@udondan

Yeah @udondan the scroll speed config isn't working known issue we will fix

The new linear default should be better in this case though in the latest version.

It definitely is! Thanks. Missed that in the release notes

Oh noticed you already updated it nvm

I have tested the updated version. The update reduces the maximum scroll speed, but OpenCode inside the Zed terminal still doesn't respond correctly to the actual speed of the user's scrolling actions.

More specifically, the process of user scrolling is not just a static speed; it's a variable-speed process that every trackpad or mouse communicates to every program. When a user swipes up/down fast, the scroll speed should be fast. When the user swipes up/down slow, the scroll speed should be slow. There is an inertia / momentum that all other programs can detect and translate into the speed at which the scrolling occurs in their programs, but for some reason, OpenCode still completely ignores this inertial dynamic.

Thus, even though it's now possible to set the maximum scroll speed below 1 to eliminate the totally crazy speeds that we experienced previously, now the opposite problem exists: The maximum scroll speed is so slow when trying to quickly swipe/scroll through large amounts of chat history that it's still very tedious and frustrating to use inside the Zed terminal.

I use it in the zed terminal myself, and imo it's great, but what settings do you have?

I explained everything in my previous description. But in summary, based on my experience using OpenCode in Zed terminals:

Scrolling behavior is not a fixed-speed operation. So basing OpenCode's scroll speed on a single fixed-value parameter creates an unnatural and frustrating user experience. It doesn't matter what speed I set in the config file, the scroll speed is either too fast or too slow because OpenCode in Zed terminals completely ignores the inertia value that all other apps detect and use perfectly.

All you need to do is scroll this web page with different levels of force to see exactly what I'm talking about. If you swipe the page up fast, the intertia is strong and the scroll speed is fast. If you swipe the page up slow, the inertia is weak and the scroll speed is slow. That's the way all programs work that have any kind of scrolling capability except for OpenCode when its running in a Zed terminal.

So giving us a single fixed scroll_speed config parameter does not fix the problem because there are at least two parameters that determine the actual scroll speed in any modern app. The current scroll_speed only defines the maximum scroll speed, but it completely ignores the inertia strength that determines how fast or slow the scrolling action works after swiping a trackpad or moving the mouse with different levels of force.

Maybe there is another parameter in Go applications that fixes this problem at a more fundamental OS level so that OpenCode's scrolling behavior simply respects the underlying OS scroll speed configuration defined by the user in their OS's own mouse/trackpad configurations. But as it behaves now, OpenCode does not provide a natural scrolling experience at all when using OpenCode in Zed terminals and likely in other environments, too.

@JuliaBonita

@JuliaBonita there is a setting that youll like better tho (prolly) try this:

  "tui": {
    "scroll_acceleration": {
      "enabled": true,
    },
  },

@rekram1-node

@rekram1-node No, that just overrides the scroll_speed setting and reverts the behavior back to the original crazy speed even when the mouse/trackpad is moving very slowly. There is still something fundamentally wrong with the scrolling behavior of OpenCode when it's running inside Zed terminals and probably other environments based on the comments from other users.

The TUI ist not a Go application anymore and even though we could get the underlying OS events directly, that would not work via remote, so opentui has to rely on the escape sequences it gets from the terminal. These sequences have no other information than the scroll direction. How these sequences are triggered depends on terminal and different implementations choose to do that differently, so the events come in different frequencies across terminals. The frequency basically determines the scroll speed and includes the inertia you are describing.

You are right that for linear scroll this inertia in the frequency is suppressed, while the scroll acceleration for MacOS just accelerates and does not have an option to control that, leading to crazy speeds in some terminals. I have yet to understand why the event frequency is different across terminals.

So in opentui we need to account for the event frequency to not equal out the inertia. I hope to get to that soon.

@kommander

@kommander I appreciate your precise response. Despite the problems described in this thread, I enjoy using OC outside of Zed. It's just a little less convenient than having the terminal and all my files open in the same view.

I appreciate the work you're doing on this project. I will continue using OC in a standalone terminal until the issues in this thread are resolved.

I'm experiencing the same issue on Zed. Scroll is too fast when using the trackpad.

I'm experiencing the same issue on Zed. Scroll is too fast when using the trackpad.

zed-industries/zed#45600
Maybe this PR can fix it.

Zed has released preview version v0.221.0-pre, which includes a fix related to fast scrolling. Please give it a try and open a new issue if you encounter any further problems.

@emamulandalib

It works great! Thanks @emamulandalib 👍🏼

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

Navigation Menu

Repository navigation

[Bug] TUI movement too fast on MacBook TouchBar causing rapid screen scrolling #2795

Bug Description

Expected Behavior

Actual Behavior

Comparison with Other Tools

Environment

Steps to Reproduce

Additional Context

Possible Solutions

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug] TUI movement too fast on MacBook TouchBar causing rapid screen scrolling #2795

Description

Bug Description

Expected Behavior

Actual Behavior

Comparison with Other Tools

Environment

Steps to Reproduce

Additional Context

Possible Solutions

Activity

github-actions commented on Sep 26, 2025

rekram1-node commented on Sep 26, 2025

mahidalhan commented on Sep 26, 2025

rekram1-node commented on Sep 26, 2025

JuliaBonita commented on Nov 4, 2025

felixmccuaig commented on Nov 9, 2025

rekram1-node commented on Nov 9, 2025

udondan commented on Nov 9, 2025

rekram1-node commented on Nov 9, 2025

kommander commented on Nov 12, 2025

udondan commented on Nov 12, 2025

6 remaining items

rekram1-node commented on Nov 18, 2025

JuliaBonita commented on Nov 18, 2025

rekram1-node commented on Nov 19, 2025

JuliaBonita commented on Nov 19, 2025

rekram1-node commented on Nov 20, 2025

JuliaBonita commented on Nov 20, 2025

kommander commented on Nov 20, 2025

JuliaBonita commented on Nov 20, 2025

soyllamas commented on Jan 11, 2026

mcthesw commented on Jan 13, 2026

emamulandalib commented on Jan 21, 2026

soyllamas commented on Jan 22, 2026

github-actions commented on Mar 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions