Codex Desktop on macOS sometimes renders conversation view incorrectly

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

Summary

Codex Desktop on macOS sometimes renders a conversation incorrectly. The session view can become visually inconsistent while an agent is still working: older turn content remains partially visible, the latest assistant response appears cut off or hidden behind the composer, and the input composer overlays the conversation area. This makes the current state of the session hard to read and hard to control.

The issue has a major impact on the user experience because the user cannot reliably tell whether Codex is still thinking, whether the latest response has completed, or whether a follow-up message will be applied to the correct turn.

Environment

  • App: Codex Desktop
  • Platform: macOS desktop app
  • macOS: 26.2, build 25C56
  • Codex app version: 26.623.141536
  • Codex app build: 4753

What happened

During normal use of Codex Desktop, the conversation display became abnormal:

  • The visible conversation showed stale/previous turn content mixed with the current turn.
  • The assistant response area appeared partially cut off.
  • The message composer floated over the conversation content and obscured text.
  • The left side of the conversation area showed repeated dotted/placeholder-like vertical artifacts.
  • The user could not comfortably read the latest response or continue the session with confidence.

The reporter is using the macOS desktop version. A screenshot was captured showing the broken state.

Expected behavior

Codex Desktop should keep the conversation view stable and readable:

  • Current and previous turns should render in the correct order.
  • The latest assistant response should not be clipped or hidden behind the composer.
  • The composer should stay anchored below the visible transcript without covering content.
  • Any in-progress state should remain visually clear and recoverable.

Actual behavior

The conversation transcript and composer overlapped visually, making the session appear corrupted or out of sync.

Request

Please fix the conversation rendering/state issue in Codex Desktop. Since this kind of UI failure can consume user time and usage while the session is not reliably readable or controllable, please also provide a one-time reset opportunity for affected users.

Notes

This appears to be a desktop app/session rendering issue rather than a model response quality issue.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30975

Powered by Codex Action

ndj888 · 1 month ago

I reviewed #30975. It appears related at the renderer/reflow layer, but it is not an exact duplicate: #30975 is a Windows report focused on stale glyph fragments and CJK/table streaming redraw, while this report is on macOS and includes the composer overlapping the transcript, a clipped latest response, and stale turn mixing. I am keeping this open unless maintainers prefer a cross-platform canonical tracker.

freshgo-tw · 1 day ago

Windows reproduction confirmed on Codex App 26.820.7780.0.

Environment

  • Platform: Windows desktop app
  • Codex App version: 26.820.7780.0
  • Subscription: paid ChatGPT account

Issue
After the latest update, the bottom composer overlays the newest assistant progress/message. The conversation scroll area does not reserve enough bottom padding, so the latest content is obscured while the agent is working.

Steps to reproduce

  1. Open a conversation with a long-running task.
  2. Let the assistant stream progress updates.
  3. Observe the newest lines at the bottom of the conversation.

<img width="1098" height="346" alt="Image" src="https://github.com/user-attachments/assets/31ae468c-dc3d-4376-bdce-1ed6aa83fd15" />

Actual behavior
The composer floats over the transcript and hides the newest assistant content, even when the composer is empty. Reading current progress requires repeated manual scrolling or window resizing.

Expected behavior
The conversation viewport should reserve space equal to the composer height, keeping the latest assistant output fully visible above it.

Impact
This makes it difficult for a paid user to monitor active work and tell whether the latest step completed. The screenshot attached shows the overlap.

This appears to reproduce the same renderer/reflow symptom described in #31711 and #40788, now on Windows App 26.820.7780.0.

SimpleZion · 20 hours ago

Windows reproduction is still present in the newer Codex Desktop build 26.820.9563.0 (observed on August 27, 2026).

Environment

  • Codex Desktop: 26.820.9563.0 (Microsoft Store package)
  • OS: Windows 11 Home 23H2, build 22631, x64
  • Display scaling: 150%
  • Model at the time: GPT-5.6 Sol, High reasoning (likely unrelated)

Observed behavior
While a local task is streaming a multi-paragraph response and the conversation is pinned to the bottom, the newest assistant lines render behind the fixed composer. The scrollbar thumb is already at its lowest position, but the obscured lines still cannot be brought into view.

This is not merely a case of the user being scrolled upward: the available scrolling range itself does not reserve enough bottom space for the composer while streaming.

Expected behavior
The conversation viewport bottom padding and auto-scroll target should dynamically account for the current composer height, keeping the latest assistant output fully visible above the composer throughout streaming.

Impact
The user cannot read or monitor the active output and cannot reliably determine whether Codex is still working, waiting, or proposing an action.

The screenshot was intentionally not attached because the underlying task contains private network details. It clearly shows the response continuing underneath the composer while the vertical scrollbar is already at the bottom.

This confirms that the Windows reproduction reported above persists after the update from 26.820.7780.0 to 26.820.9563.0.