Codex app enters an infinite scroll loop after using the jump-to-bottom button
https://github.com/user-attachments/assets/4733e283-92a3-4dfa-9fda-de54150d2719
Description
When opening an existing long session, the conversation sometimes remains at or restores to an incorrect position near the beginning instead of the latest message.
Pressing the down-arrow / jump-to-bottom button can then put the session into an infinite scroll loop.
The viewport repeatedly alternates between:
- an earlier section of the conversation;
- the latest section of the conversation;
- a blank area where the conversation content temporarily disappears.
The loop continues without any additional user input and makes the session unusable.
I attached a video showing the full behavior.
Steps to reproduce
- Open an existing long Codex session.
- Wait for the conversation to load.
- If the session remains at an earlier position, press the down-arrow button to jump to the latest message.
- Observe the viewport.
Actual behavior
The app repeatedly jumps between different positions in the conversation and a blank viewport.
The jump-to-bottom action does not settle at the latest message and instead triggers a continuous scrolling or rendering loop.
Expected behavior
Pressing the jump-to-bottom button should:
- scroll to the latest message once;
- render the conversation normally;
- stop scrolling without further movement.
Frequency
Intermittent. It does not happen every time a session is opened, but once triggered, the loop continues repeatedly.
Additional observations
- The issue appears more likely in long sessions.
- The blank state suggests that conversation items may be temporarily unmounted or incorrectly positioned while the scroll location is being restored.
- It may involve an interaction between session scroll restoration, automatic scrolling, and conversation list virtualization.
- This is only a possible explanation based on the visible behavior; I have not confirmed the underlying cause.
Environment
- Codex app
- Operating system: Windows
- Session type: existing long conversation
The attached video provides the clearest reproduction of the issue.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I can reproduce what looks like the same scroll-anchor/restoration bug in the Codex desktop app, with one additional trigger path:
Expected: when reopening the thread or after sending a new request, the view should anchor to the latest/bottom message, unless the user is intentionally reading older content.
Actual: the thread restores to the previous quick-jump position instead of the bottom. In very long threads this makes the current turn appear far above/below the visible viewport, and the user has to manually scroll/jump back to the bottom again.
This feels like the quick-jump position is being persisted as the thread's default scroll restore position, and then reused even for cases where the app should bottom-anchor, such as reopening the session or starting a new request.
I can reproduce this on Codex App 26.715.12143 on Windows 11 24H2 (build 26100.4351, x64).
The conversation pane rapidly alternates between unrelated earlier/later scroll positions and a blank viewport, while the sidebar, title bar, and composer remain stationary.
The issue persists after fully restarting Codex and reopening the same task.
The trigger is uncertain: the behavior became observable after the final conversation turn, but the recording started after it was already occurring. Therefore, I cannot determine whether it began when the prompt was sent or while the assistant response was being received.
Feedback ID: 019f7d4d-60d5-7003-8452-6be282dca442