Long threads can jump back to top while scrolling downward toward latest output

Open 💬 4 comments Opened Apr 9, 2026 by overFloweee

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug Report

App version: 26.406.31014 (1395)
Platform: macOS

Description

In very long conversations, scrolling downward toward the latest output can suddenly reset the viewport back to the top of the thread.

This makes it very difficult to get back to the newest messages in long chats.

This may be related to #17169, but the user-visible symptom here is specifically:

not just scrolling up causing a jump to the center
but also scrolling downward in long threads causing the view to jump back to the top

Steps to Reproduce

Open Codex app on macOS (version 26.406.31014 / build 1395)
Open a conversation with a very long history
Start from somewhere above the latest messages
Scroll downward toward the newest output

Expected

The thread should keep its current scroll position and allow smooth navigation toward the latest output.

Actual

The viewport can unexpectedly jump back to the top of the conversation, forcing the user to scroll down again.

Impact

High. In long threads, returning to the latest output becomes very time-consuming and frustrating.

Additional Context

This started after updating to 26.406.31014 (1395).

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#17169

Powered by Codex Action

overFloweee · 4 months ago

I did some local inspection of the packaged app code, and this looks like it may be more than a simple CSS scroll glitch.

A likely root cause area is the thread scroll system itself:

The thread container appears to use flex-col-reverse.
It also appears to model scrolling in terms of distance from bottom, including a negative/translated scrollTop mapping.
The container explicitly disables browser scroll anchoring with overflow-anchor: none.
There is custom logic to compensate for message height changes (for example when streamed output grows or when rendered content changes height).
There is also separate auto-follow / auto-scroll-to-bottom behavior gated by a small “near bottom” threshold.

From inspection, the logic seems roughly equivalent to:

treat “bottom” as the primary anchor
auto-follow while the user is still considered near the bottom
preserve visual position when message heights change

That makes sense as a product goal, but it also means multiple systems are interacting at once:

reversed layout
custom bottom-distance math
manual scroll restoration / compensation
auto-scroll-to-bottom
disabled browser overflow anchoring

My guess is that in long conversations, once content height changes or the thread re-renders, these mechanisms can disagree and produce the visible symptom where the viewport jumps unexpectedly (including jumping back toward the top when navigating downward).

So this may be worth investigating specifically as a regression in:

thread scroll state restoration
bottom-anchor calculations
height-delta compensation after streamed/rendered content grows
interaction between custom auto-follow logic and the reversed thread layout

sebas1111111 · 4 months ago

fix this

alibrohde · 2 months ago

+1, I’m seeing this on macOS too.

In long Codex Desktop threads, I’ll scroll back up to review older output, then have trouble getting back to the newest message. The pane sometimes jumps around or won’t actually settle at the bottom for a bit.