# Cursor-agent CLI: mouse scroll in Ghostty snaps back to bottom (Codex does not) **URL:** \ **Category:** Bug Reports\ **Tags:** cli, terminal\ **Created:** [August 15, 2026, 1:59am UTC](https://forum.cursor.com/t/cursor-agent-cli-mouse-scroll-in-ghostty-snaps-back-to-bottom-codex-does-not/168449 "2026-08-15T01:59:07Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![wangfengcsu](https://avatars.discourse-cdn.com/v4/letter/w/ce7236/32.png) [@wangfengcsu](https://forum.cursor.com/u/wangfengcsu)\ **Post date:** [August 15, 2026, 1:59am UTC](https://forum.cursor.com/t/cursor-agent-cli-mouse-scroll-in-ghostty-snaps-back-to-bottom-codex-does-not/168449/1 "2026-08-15T01:59:07Z")
### Where does the bug appear (feature/product)? Cursor CLI (`cursor-agent`) ### Describe the Bug In Ghostty, while using `cursor-agent`, scrolling up with the mouse / trackpad to read earlier output immediately jumps the viewport back to the bottom. This is not a Ghostty config issue: **Codex CLI in the same Ghostty terminal, same profile, does not snap back.** Scrolling stays where I left it. It looks like `cursor-agent`’s TUI keeps auto-following / redrawing the latest line (alternate screen + mouse tracking + frequent re-renders), so any manual scroll is overwritten on the next frame. Related threads (same TUI scroll problem, different symptoms): - [When using cursor agent (or cursor cli?) on Ubuntu, I cannot scroll the the results](https://forum.cursor.com/t/when-using-cursor-agent-or-cursor-cli-on-ubuntu-i-cannot-scroll-the-the-results/145727) - [[FEATURE] Pin composer box to bottom of terminal pane (Cursor CLI)](https://forum.cursor.com/t/feature-pin-composer-box-to-bottom-of-terminal-pane-cursor-cli/162397) (staff: not being able to scroll terminal output while the prompt is visible is already on your radar) ### Steps to Reproduce 1. Open Ghostty on macOS. 2. Run `cursor-agent` and produce more than one screen of output (streaming reply or tool output). 3. Scroll up with the mouse / trackpad to read earlier content. 4. The view snaps back to the bottom almost immediately. 5. Repeat in the same Ghostty profile with Codex CLI — the scroll position stays put. ### Expected Behavior Scrolling up should pause auto-follow until I return to the bottom, same as Codex. ### Operating System macOS 26.2 (Build 25C56) ### Version Information - cursor-agent: `2026.08.11-e8db854` - Ghostty: `1.3.1` (stable) - Ghostty `mouse-reporting = true` (Cmd+Shift+M toggles it). Codex still scrolls normally with this config. ### Does this stop you from using Cursor No — Cursor works, but reviewing long CLI sessions is painful. ---
**Author:** ![kevinn](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/kevinn/32/101206_2.png) [@kevinn](https://forum.cursor.com/u/kevinn)\ **Post date:** [August 19, 2026, 4:31am UTC](https://forum.cursor.com/t/cursor-agent-cli-mouse-scroll-in-ghostty-snaps-back-to-bottom-codex-does-not/168449/8 "2026-08-19T04:31:22Z")
Thanks for the post! You’re right that this isn’t your Ghostty config, and it’s not specific to Ghostty either. The mechanism is a little different from your guess, in a way that matters for workarounds: the CLI doesn’t use the alternate screen or request mouse tracking on the main chat view, so `mouse-reporting` isn’t involved. What happens is that the live region at the bottom (streaming text, status, input box) gets rewritten in place many times a second, and once that region grows taller than the window the redraw falls back to a full clear that wipes scrollback. There’s nowhere for your scroll position to survive, so the viewport pins to the bottom. Two things that help today: scrolling works normally once the agent is idle, and a taller terminal window makes the full-clear path fire much less often during a turn. This is an issue we’re tracking, and your Ghostty datapoint is a useful one to add. I’ll post here when I have an update.