Codex desktop viewport jumps and composer overlays text while user is reading scrolled history
Summary
When reading a Codex desktop task while scrolled above the bottom, the conversation viewport repeatedly jumps/reflows without user input. The floating composer also overlays message content instead of reserving vertical space, hiding the text the user is trying to read.
This happened repeatedly in one task while the user was reading prior assistant messages. The user was not interacting with the input/composer when at least one jump occurred.
Environment
- App: Codex desktop / ChatGPT Windows Store package
- Package:
OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0 - Version:
26.803.10989.0 - SignatureKind: Store
- OS: Windows, user environment path indicates Windows desktop
Steps to reproduce
- Open a long Codex task with enough messages to scroll.
- Scroll upward to read prior assistant text, not at the bottom.
- Continue reading while the task/composer is idle, or while new nearby content/layout settles.
- Observe the viewport unexpectedly jump/reflow.
- Observe the composer overlaying the message area and hiding text behind the input box.
Actual behavior
- Reading position is not preserved while scrolled above the bottom.
- The viewport jumps/reflows repeatedly.
- The bottom composer overlays readable message content.
- Text being read is pushed under/behind the composer.
- A jump-to-bottom affordance is visible, but the app still changes the viewport while the user is reading.
Expected behavior
- If the user is scrolled above the bottom, preserve the scroll anchor.
- Do not auto-scroll/reflow the viewport unless the user explicitly jumps to bottom or is already at bottom.
- Reserve bottom padding/layout space equal to the composer height.
- Never allow the composer to cover message text.
- If new messages/content arrive while the user is scrolled up, show a non-disruptive “new message” affordance.
Suggested implementation direction
- Track whether the scroll container is near bottom before content/composer size changes.
- If not near bottom, preserve the currently visible message/scroll anchor through layout changes.
- If near bottom, continue auto-scroll behavior.
- Ensure the message list has bottom padding equal to the composer height rather than relying on overlay behavior.
Pseudo behavior:
const wasAtBottom = isNearBottom(scrollContainer)
onContentOrComposerResize(() => {
if (wasAtBottom) scrollToBottom()
else preserveScrollAnchor()
})
Screenshots captured locally
The user provided screenshots showing the composer covering message text and the reading viewport jumping:
C:/Users/mattr/AppData/Local/Temp/codex-clipboard-1cdf1cbd-35da-41ad-a1d7-84bc85ec9905.pngC:/Users/mattr/AppData/Local/Temp/codex-clipboard-e1f7a3ab-068b-4a33-b6ec-b6406e859f6c.pngC:/Users/mattr/AppData/Local/Temp/codex-clipboard-9591ef57-eb5b-4b3c-96fe-49357eb7f09a.png
I cannot attach those local files through this connector, but they demonstrate the issue clearly: the composer floats over the lower message text while the user is scrolled up and reading.
3 Comments
Correction/clarification: the screenshot paths listed in the original report are local temp paths from the reporter's Windows machine and are not accessible to maintainers. They should be treated only as evidence that screenshots were provided in-session, not as usable attachments.
What the screenshots show:
The actionable bug is independent of those local file paths: preserve scroll position while the user is reading history and reserve bottom layout space so the composer cannot cover message content.
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional current-build reproduction on Windows:
OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0Deterministic trigger:
Recovery attempts that did not help:
Ctrl+0EndThe process remains responsive and there is no matching renderer crash or Windows Error Reporting event.
Read-only inspection of this signed package's renderer bundle shows that the thread scroll layout derives bottom clearance from a
ResizeObserver-managed--thread-scroll-padding-bottomvalue plus a sticky spacer. Since the initial footer measurement can succeed but clearance is lost specifically after the scroll-away -> scroll-to-bottom cycle, this looks like scroll-anchor/spacer restoration rather than a DPI, zoom, or initial composer-height problem.The symptom was first noticed after the Store auto-update from
26.820.7780.0to26.820.9563.0, but no rollback A/B was performed, so that is correlation rather than proof of the first bad build.No chat content, local paths, raw logs, or profile data are attached.