Codex desktop viewport jumps and composer overlays text while user is reading scrolled history

Open 💬 3 comments Opened Aug 12, 2026 by mattrdell
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Open a long Codex task with enough messages to scroll.
  2. Scroll upward to read prior assistant text, not at the bottom.
  3. Continue reading while the task/composer is idle, or while new nearby content/layout settles.
  4. Observe the viewport unexpectedly jump/reflow.
  5. 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.png
  • C:/Users/mattr/AppData/Local/Temp/codex-clipboard-e1f7a3ab-068b-4a33-b6ec-b6406e859f6c.png
  • C:/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.

View original on GitHub ↗

3 Comments

mattrdell · 15 days ago

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 user is scrolled above the bottom of a long Codex task.
  • The floating composer/input box sits over the lower portion of assistant message text.
  • The visible reading position changes/reflows repeatedly while the user is trying to read.
  • The jump-to-bottom affordance is visible, but the viewport still shifts/obscures content instead of preserving the scroll anchor.

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.

github-actions[bot] contributor · 15 days ago

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

  • #37872
  • #37608
  • #37849
  • #38113

Powered by Codex Action

smart-tinker · 22 hours ago

Additional current-build reproduction on Windows:

  • Microsoft Store package: OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0
  • Windows x64; app window at 100% DPI, with no custom text scaling or forced device-scale-factor
  • The issue affects some long local tasks

Deterministic trigger:

  1. Open an affected long task.
  2. Scroll upward with the mouse wheel.
  3. Scroll back to the bottom.
  4. The final transcript lines are now rendered beneath the opaque floating composer.
  5. Further mouse or keyboard/end-of-thread scrolling cannot expose the obscured lines.

Recovery attempts that did not help:

  • Ctrl+0
  • restore/maximize or resize the window
  • full tray quit and reopen (a new main process was created)
  • focus the transcript and press End
  • expand and shrink an empty composer to force a fresh footer-height measurement

The 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-bottom value 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.0 to 26.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.