[macOS][Desktop 26.727.51351] Long thread intermittently opens on early history despite successful pagination

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

26.727.51351 (build 6119), with bundled codex-cli 0.146.0-alpha.9.2.

What subscription do you have?

GPT Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm

macOS 26.6 (25G72).

What issue are you seeing?

A long local Codex thread intermittently opens with only an early portion of the conversation visible. The latest turns appear to be missing from the transcript. Reloading or reopening the same thread several times can make the latest content reappear.

The persisted thread is intact, and the app-server successfully returns the current thread plus every requested history page. This looks like a Desktop transcript hydration, virtualized-list, or scroll-anchor state problem rather than data loss.

Sanitized thread characteristics:

• Rollout size: 55,336,970 bytes
• JSONL records: 27,101
• Task turns reported by Desktop resume: 64
• The Codex thread-reading API can return the newest page and latest completed turn

Sanitized diagnostics captured during an affected reopen at 2026-08-04 01:58:39Z:

• thread/read succeeded in 12 ms with errorCode=null
• thread/resume succeeded in 316 ms with errorCode=null
• Resume reported latestTurnStatus=completed while renderer state simultaneously reported markedStreaming=true
• Desktop then issued 14 sequential thread/turns/list requests
• All 14/14 page requests succeeded with errorCode=null
• Individual page responses took approximately 249–496 ms
• The same UI activity window produced repeated ResizeObserver loop completed with undelivered notifications renderer errors, including a dense cluster immediately after the thread became active

Despite successful storage and pagination responses, the UI exposed the wrong portion of the transcript. A later reload could render the newest turns normally.

What steps can reproduce the bug?

1. Use a local Codex Desktop thread until it has a substantial transcript (the affected rollout is approximately 55 MB).
2. Switch to another thread or view.
3. Reopen the long thread from the sidebar.
4. Intermittently, observe that the conversation pane shows an early portion of history and the latest turns are not reachable or visible.
5. Reload or reopen the thread repeatedly.
6. Eventually, the latest content may appear again without any change to the underlying rollout.

The failure is intermittent; short threads do not show the same behavior.

What is the expected behavior?

The newest stored turns should be displayed immediately when the thread opens. Older history may load lazily, but successfully returned pages should be merged into one canonical transcript without replacing the current tail or restoring an obsolete scroll anchor.

A completed latest turn should not be restored with markedStreaming=true. If history hydration is still in progress, Desktop should show an explicit loading or recovery state instead of presenting an apparently complete but stale transcript.

Additional information

Related reports:

• #35431 — long Desktop thread reopens at an old message instead of the latest content
• #31995 — long Desktop conversations expose only part of intact paginated history
• #21211 — eager large-history hydration and rendering performance
• #17193 — macOS long-thread scroll position jumps away from latest output

This report intentionally omits the thread ID, local paths, raw rollout, prompts, account details, and full logs because they contain private project data. I can provide additional sanitized log excerpts if maintainers request them.