[Desktop] Long conversations show only recent turns after update although full rollout history remains local
Summary
After updating to the ChatGPT desktop app that includes Codex, opening existing long conversations shows only the most recent turns. Older turns are not accessible in the conversation UI, even though the complete rollout files remain present and the app-server successfully pages through stored turns.
This reproduces across multiple existing long conversations and looks like a Desktop transcript hydration/rendering regression rather than data loss.
Environment
- Product: ChatGPT desktop app with Codex
- Desktop app version:
26.707.31428 - Bundled Codex version:
codex-cli 0.144.0-alpha.4 - OS: macOS 15.7.3
- Architecture: arm64
- Local thread history mode: existing threads are marked
legacy
Steps to reproduce
- Have one or more existing Codex conversations with substantial history.
- Update to the ChatGPT desktop app build above.
- Open an existing long conversation.
- Scroll upward and try to reach the beginning of the transcript.
- Only the recent portion of the conversation remains visible; earlier turns cannot be reached.
Expected behavior
The complete stored conversation should be viewable. Incremental history loading may be used for performance, but all older pages should eventually be merged into the transcript while preserving a usable scroll position.
Actual behavior
Only the recent turns are rendered in the conversation view. The UI behaves as if older history is unavailable, even though the storage and app-server layers still contain and return it.
Local diagnostics
The following checks were performed without modifying any Codex data:
PRAGMA integrity_checkon~/.codex/state_5.sqlite:ok- Thread rows in the state database: 1,504
- Corresponding rollout files found: 1,504
- Missing rollout files: 0
- Empty rollout files: 0
- Active session storage: approximately 1.9 GB
- Archived session storage: approximately 705 MB
- A
threads history modemigration was applied during the update; all existing rows currently reporthistory_mode = legacy - Desktop logs recorded 40 successful
thread/turns/listresponses witherrorCode=null - No
Failed to load older thread turnsorFailed to load remaining thread turns after resumemessages were found - The renderer repeatedly logged:
ResizeObserver loop completed with undelivered notifications.
- In one long-conversation window, 21 successful history-page responses were followed by 129 of those renderer errors
This suggests the rollout reader and pagination API are working, but the Desktop renderer or virtualized transcript state is not reliably exposing the hydrated older turns.
Suggested areas to inspect
- Merging
thread/turns/listpages into canonical transcript state - Virtualized-list scroll anchoring when older pages are prepended
- Whether repeated
ResizeObservererrors prevent older entries from becoming reachable - Compatibility between
history_mode = legacy, tail hydration, and canonical turn history - A visible recovery/loading state when older turns cannot be rendered
Related issue
#21211 discusses large-thread hydration and rendering performance, but this report is specifically about successful history-page responses not becoming accessible in the Desktop transcript.
Raw session transcripts and full logs are intentionally not attached because they may contain sensitive data. Sanitized excerpts can be provided if needed.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I reviewed #31047 and believe this is a different failure mode. In #31047, existing threads render completely blank and the report includes intermittent SIGKILL crashes. In this issue, existing long threads open successfully and recent turns render normally, but older paginated turns cannot be reached. The
thread/turns/listrequests complete successfully, and no thread-loader failure or crash was observed.This appears to be a transcript hydration/virtualized-rendering issue rather than a blank-thread or process-crash issue. If maintainers determine that both share the same root cause, I am happy to consolidate this report.
I can confirm the same failure mode on another long local Codex Desktop thread.
Additional diagnostics
0.146.0-alpha.3.1history_mode: legacythread/rollbackwarning appears unrelatedExpected behavior: every stored user/final-agent message should remain reachable in the Desktop conversation, including the tail of a long legacy thread after compaction.
I am intentionally not attaching the raw transcript or local paths because they contain private project information. Sanitized event summaries can be provided if useful.
The important control here is that all 1,504 rollouts exist, pagination calls succeed, and only the older rendered turns disappear after the update. That makes this a reconstruction/client boundary rather than proven transcript loss.
I’m trying to validate whether Codex Rescue reports those long local sessions as structurally intact and avoids a false corruption diagnosis. It is local-first and does not change the rollout, SQLite, history mode, or Desktop UI. It also does not claim broad compaction recovery.
If one affected conversation still exists, could you run:
pipx install codex-rescue==0.1.0a3codex-rescue sessionscodex-rescue doctor --latestSanitized output is sufficient—please don’t share raw transcripts, databases, logs, prompts, paths, or secrets.
https://github.com/shleder/codex-rescue