Codex Desktop macOS: Archived Conversations page corrupts/blank overlay after scrolling

Resolved 💬 3 comments Opened Jun 11, 2026 by Byebai13 Closed Jun 11, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop App: 26.608.12217, build 3722

Bundled Codex CLI:

codex-cli 0.138.0-alpha.7

What subscription do you have?

No response

What platform is your computer?

macOS 26.4.1 build 25E253, Apple Silicon / arm64

What issue are you seeing?

The Settings -> Archived Conversations / 已归档对话 page becomes visually corrupted after scrolling a few times. It looks like a renderer/layout/virtualized-list failure rather than a normal app exit.

Observed behavior from a 16-second local recording:

  1. Open Codex Desktop.
  2. Go to Settings.
  3. Open Archived Conversations / 已归档对话.
  4. Two-finger scroll / swipe a few times.
  5. The archived conversations list area turns into a large pale red / blank block.
  6. The overlay then expands/covers the main content area and part of the left settings sidebar.
  7. The UI does not recover in that view; restarting Codex is currently the reliable workaround.

This is distinct from opening a long conversation and scrolling inside the chat transcript. The repro surface here is the archived conversations browser under Settings.

Related but not identical: #27168 reports blank rendering while scrolling long conversations. This issue is specifically about Archived Conversations page scrolling on macOS.

What steps can reproduce the bug?

  1. Launch Codex Desktop on macOS.
  2. Open Settings.
  3. Click Archived Conversations / 已归档对话 in the left settings sidebar.
  4. Scroll the archived conversations page/list a few times.
  5. Observe the page becoming blank/corrupted with a large pale overlay.

What is the expected behavior?

The archived conversations page should remain stable while scrolling, including when there are no visible archived items or when the list is empty/loading.

Additional information

Local checks after the repro:

  • No matching macOS ~/Library/Logs/DiagnosticReports native .crash report was created at the repro time.
  • No fresh Crashpad .dmp appeared at the repro time.
  • Codex main process and renderer processes were still running after the visual corruption.
  • Unified logs did not show a clear render-process-gone or native crash signal during the repro window.
  • App logs under ~/Library/Logs/com.openai.codex/2026/06/11/ continued to show normal request routing around the same time; no obvious fatal renderer crash appeared.

This suggests the app is not necessarily exiting; the visible failure looks more like renderer/compositor/layout state corruption in the archived conversations settings page.

I have a short local video recording of the repro, but I am not attaching it publicly because it contains local UI/account context. I can share a redacted recording or targeted logs if useful.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗