[Desktop] Long conversations show only recent turns after update although full rollout history remains local

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

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

  1. Have one or more existing Codex conversations with substantial history.
  2. Update to the ChatGPT desktop app build above.
  3. Open an existing long conversation.
  4. Scroll upward and try to reach the beginning of the transcript.
  5. 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_check on ~/.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 mode migration was applied during the update; all existing rows currently report history_mode = legacy
  • Desktop logs recorded 40 successful thread/turns/list responses with errorCode=null
  • No Failed to load older thread turns or Failed to load remaining thread turns after resume messages 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/list pages into canonical transcript state
  • Virtualized-list scroll anchoring when older pages are prepended
  • Whether repeated ResizeObserver errors 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.

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.

  • #31047

Powered by Codex Action

xiaoliuxiaoliu · 1 month ago

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/list requests 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.

caokaizz · 29 days ago

I can confirm the same failure mode on another long local Codex Desktop thread.

Additional diagnostics

  • Platform: macOS
  • The thread was created by Codex Desktop with bundled Codex 0.146.0-alpha.3.1
  • Thread metadata reports history_mode: legacy
  • The rollout JSONL is intact: 13,009,678 bytes / 2,383 lines
  • It contains 11 completed task turns, 11 user messages, and 61 agent messages
  • The thread underwent 2 context compactions
  • The final three agent messages (written one minute apart at the end of the run) are still present in the rollout JSONL, but are not visible in the Desktop transcript
  • The stored thread can still be inspected through the app's thread-reading API, confirming this is not data loss
  • No rollback event exists in the rollout, so the deprecated thread/rollback warning appears unrelated
  • Copying the missing final messages into a new task in the same project makes them display normally

Expected 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.

shleder · 14 days ago

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.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized output is sufficient—please don’t share raw transcripts, databases, logs, prompts, paths, or secrets.

https://github.com/shleder/codex-rescue