What happened?
Running Cursor CLI (agent) in a terminal surface, switching between worktrees or tabs makes the session viewport jump to the top and scroll back down, every time. It only happens on a non-HiDPI (1×) display; on a Retina/HiDPI display the same actions don't move the viewport.
This is a regression in v0.10.6. On v0.10.5 it doesn't happen on any display.
The trigger is display backing scale, not window resizing. Proven by toggling a single variable on the same physical monitor:
- Dell U2422HE at 1920×1080 "(low resolution)" (1× backing) → bug present, tab/worktree switch scrolls to top every time.
- Same monitor at a HiDPI mode (2× backing, e.g. the non-"low resolution" 1024×576, or a scaled 1920×1080 HiDPI via BetterDisplay) → no scroll, viewport stays put.
- Built-in Liquid Retina XDR (2× backing) → never reproduces.
No window resize is involved — the window is fullscreen and its size never changes. Plain Ghostty outside Supacode does not scroll under the same conditions, and Claude Code in the same surface does not scroll either (it repaints without moving the viewport).
Expected: switching worktrees/tabs should not move the viewport of a long-running TUI, regardless of display backing scale — matching v0.10.5 and the HiDPI case.
Likely area: The suspect is #570 "Per-surface terminal backgrounds and terminal-driven window appearance" — the only v0.10.6 change touching the surface/layout path.
Its new tint-backdrop compositing drives extra surface relayouts on focus/tab changes (applyWindowAppearance + the new .ghosttySurfaceFrameDidChange post in GhosttySurfaceView.layout()). Each relayout runs notifySizeChanged() → updateSurfaceSize(), which guards on convertToBacking(bounds.size) == lastBackingSize. At 1× backing that guard appears fragile: a relayout that keeps the same logical bounds can round to a different integer backing size, so ghostty_surface_set_size() fires a spurious pty resize and the CLI repaints from the top. At 2× the rounding absorbs the jitter and the guard holds — which is exactly why HiDPI is unaffected. A guard on the resolved cell grid (cols×rows), or not re-signaling the pty when the grid is unchanged, would likely fix it.
Steps to reproduce
- Connect a non-HiDPI external display, or set any display to an explicit 1× mode (macOS Displays → a "(low resolution)" entry).
- Open Supacode fullscreen on that display.
- In a terminal surface, run a long-running full-screen TUI (Cursor CLI: agent) and sit at the bottom of its scrollback.
No window resize is involved — the window is fullscreen and its size never changes. Plain Ghostty outside Supacode does not scroll under the same conditions, and Claude Code in the same surface does not scroll either (it repaints without moving the viewport).
Expected: switching worktrees/tabs should not move the viewport of a long-running TUI, regardless of display backing scale — matching v0.10.5 and the HiDPI case.
Supacode version and build
0.10.6 (1783877721)
macOS version
macOS 26.5.2
System locale
en_US
Mac hardware
M1 Pro (MacBookPro18,3)
Relevant logs or screenshots
Screen recording of bug here
https://www.loom.com/share/4b889ec6dcbc4627a33a6ab0d4089042
Are you planning to fix this yourself?
Before submitting
What happened?
Running Cursor CLI (agent) in a terminal surface, switching between worktrees or tabs makes the session viewport jump to the top and scroll back down, every time. It only happens on a non-HiDPI (1×) display; on a Retina/HiDPI display the same actions don't move the viewport.
This is a regression in v0.10.6. On v0.10.5 it doesn't happen on any display.
The trigger is display backing scale, not window resizing. Proven by toggling a single variable on the same physical monitor:
No window resize is involved — the window is fullscreen and its size never changes. Plain Ghostty outside Supacode does not scroll under the same conditions, and Claude Code in the same surface does not scroll either (it repaints without moving the viewport).
Expected: switching worktrees/tabs should not move the viewport of a long-running TUI, regardless of display backing scale — matching v0.10.5 and the HiDPI case.
Likely area: The suspect is #570 "Per-surface terminal backgrounds and terminal-driven window appearance" — the only v0.10.6 change touching the surface/layout path.
Its new tint-backdrop compositing drives extra surface relayouts on focus/tab changes (applyWindowAppearance + the new .ghosttySurfaceFrameDidChange post in GhosttySurfaceView.layout()). Each relayout runs notifySizeChanged() → updateSurfaceSize(), which guards on convertToBacking(bounds.size) == lastBackingSize. At 1× backing that guard appears fragile: a relayout that keeps the same logical bounds can round to a different integer backing size, so ghostty_surface_set_size() fires a spurious pty resize and the CLI repaints from the top. At 2× the rounding absorbs the jitter and the guard holds — which is exactly why HiDPI is unaffected. A guard on the resolved cell grid (cols×rows), or not re-signaling the pty when the grid is unchanged, would likely fix it.
Steps to reproduce
No window resize is involved — the window is fullscreen and its size never changes. Plain Ghostty outside Supacode does not scroll under the same conditions, and Claude Code in the same surface does not scroll either (it repaints without moving the viewport).
Expected: switching worktrees/tabs should not move the viewport of a long-running TUI, regardless of display backing scale — matching v0.10.5 and the HiDPI case.
Supacode version and build
0.10.6 (1783877721)
macOS version
macOS 26.5.2
System locale
en_US
Mac hardware
M1 Pro (MacBookPro18,3)
Relevant logs or screenshots
Are you planning to fix this yourself?
ready.Before submitting
ready.