Desktop App: paginated thread history is replaced by a single interrupted initial turn after update #40452

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Aug 24, 2026
2. github-actions commented on Aug 24, 2026

   

   github-actionsBot

   on Aug 24, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Bug] Paginated thread history projection stops at a token_count record #40342

   Powered by Codex Action
3. someone114514 commented on Aug 26, 2026

   

   someone114514

   on Aug 26, 2026

   More actions

   I can corroborate this on a newer Windows Desktop build, with a precise restart/resume trace and an active Goal continuation.

   Environment

   • Windows x64, Microsoft Store Desktop package
   • Codex Desktop: 26.818.5229.0
   • Bundled app-server: 0.149.0-alpha.4.1
   • Local thread with paginated history

   Observed sequence (UTC)

   1. The initial turn emitted task_started at 2026-08-25T14:25:27Z and persisted normal messages/tool items.
   2. At 14:31:48Z, Desktop logged Recoverable Chromium child process gone ... processType=GPU reason=crashed exitCode=2.
   3. The old window became invisible and its log ended. At 14:31:55Z, the same Desktop build launched again; there was no update or graceful-quit record.
   4. On resume at 14:32:16Z, Desktop reported the initial turn as latestTurnStatus=interrupted.
   5. At 14:32:56Z, Desktop issued thread/goal/set and started a Goal continuation with a new turn ID.
   6. The rollout never received task_complete, turn_aborted, or another terminal lifecycle event for the initial turn.
   7. The Goal continuation and multiple later turns completed normally and are present in the same valid rollout JSONL.

   Resulting inconsistency

   The rollout was about 131 MB at inspection time. A lifecycle snapshot contained 11 task_started, 8 task_complete, 1 intentional turn_aborted, and 1 then-active diagnostic turn, leaving exactly 1 historical orphaned start (the initial turn). It had also undergone 20 compactions.

   However, Desktop/app thread/read returned only the initial turn:

   status = inProgress
   completedAt = null
   page.hasMore = false
   page.nextCursor = null
   

   The later completed turns were visible in the raw rollout but absent from the read model. The UI consequently placed very early setup commentary next to much later completion/follow-up messages, making old work appear current.

   This was not project or rollout corruption: the Git worktree/commits were intact, JSONL parsed, the durable Goal had been cleared, and there were no queued follow-ups.

   Why this case may help

   This provides a concrete producer-side path for the orphan described here and in #40836:

   active turn
   -> Desktop/GPU process loss and app relaunch
   -> thread/resume reconstructs turn as interrupted
   -> Goal continuation starts a newer turn
   -> no terminal event/projection finalization is persisted for the older turn
   -> paginated thread/read stops at the orphan and hides later completed turns
   

   Expected recovery behavior:

   • When resume reconstructs an orphan as interrupted, persist/finalize that state in the paginated projection.
   • Starting a newer turn should implicitly close any older non-live turn.
   • Projection should group/continue by explicit turn_id; an older orphan must not act as a pagination barrier.
   • A supported projection rebuild/repair command would help existing affected threads.

   I did not edit the JSONL or SQLite state and have not attached raw logs because they contain private prompts, local paths, and tool output. I can provide a sanitized event fixture or submit the existing session through in-app feedback if maintainers need it.
4. ikekou commented on Aug 29, 2026

   

   ikekou

   on Aug 29, 2026

   More actions

   Additional macOS reproduction: network interruption followed by stale thread history

   I can reproduce the same completed-rollout-to-single-interrupted-turn failure on macOS.

   Environment

   • macOS 26.0.1 (build 25A362), Apple Silicon
   • Codex Desktop 26.825.32147 (build 7303)
   • Bundled app-server/CLI recorded in session metadata: 0.150.0-alpha.12.2
   • history_mode=paginated

   Timeline

   • The affected task started at 2026-08-29 10:57 UTC.
   • At 11:03:48 UTC, the Desktop logs recorded net::ERR_INTERNET_DISCONNECTED and Thread catalog sync failed.
   • At 11:04:05 UTC, the logs recorded write EPIPE, followed by the local AppServerConnection transitioning through stop_process to disconnected.
   • I resumed the same task at about 11:10 UTC and continued using it normally until 23:33 UTC.
   • When reopened later, the Desktop UI/thread reader returned only the initial turn as interrupted, with no additional page (hasMore=false / no next cursor).

   Durable local evidence

   The canonical rollout JSONL is still present and parses normally:

   • 2,467 JSONL records
   • 18,267,702 bytes
   • 26 distinct turn IDs
   • 23 task_complete events
   • the final task_complete is at 23:33:46 UTC, about 12.5 hours after task creation

   However, the matching entry in session_index.jsonl still has its creation-time updated_at value (10:57:34 UTC), even though the rollout continued through 23:33 UTC.

   This suggests that the network/app-server interruption may be one trigger: later turns continue to append successfully to the canonical rollout, while the thread catalog/history projection remains pinned to the initial interrupted turn and is not reconciled afterward.

   I have not modified the rollout, index, cache, or state databases and have not attempted any repair. I have intentionally omitted raw prompts, project names, local paths, credentials, and the task ID from this public comment. I can provide the task ID and narrowly redacted log excerpts through a private support channel if useful.
5. romankoss commented on Aug 30, 2026

   

   romankoss

   on Aug 30, 2026

   More actions

   Additional Windows + ChatGPT mobile Remote reproduction, originally reported in #41707.

   I can confirm the same thread-history projection failure on a newer Windows Desktop build:

   • Host: Windows 10 Pro 64-bit, build 10.0.19042
   • Codex Desktop package: OpenAI.Codex_26.825.6671.0_x64
   • Executable version: 151.0.7922.174
   • Bundled CLI: 0.151.0-alpha.7.2 (one older affected thread originated on 0.150.0-alpha.12.2)

   The common preceding action was opening several existing Desktop-origin tasks through ChatGPT mobile Remote when the phone showed only partial/early history. Returning to Desktop left those tasks present and recent, but their projected histories had regressed.

   Sanitized evidence from two affected tasks:

   • Task A rollout: 4 meaningful user messages, 5 task_complete events, 4 non-empty final answers. Desktop/app reader: only the first interrupted turn, hasMore: false.
   • Task B rollout: 12 meaningful user messages, 12 task_complete events, 11 non-empty final answers. Desktop/app reader: only 3 turns, hasMore: false.

   The original rollout JSONL files parse successfully and retain the later completed work. session_index.jsonl timestamps were stale relative to the final rollout events.

   Recovery behavior adds another signal: sending a new recovery marker to one affected task worked immediately. For the older task, the first send advanced updatedAt but remained invisible; after explicitly navigating to/load the task and resending, a new completed turn was created. Historical pagination still remained truncated. This suggests new turns can be accepted while the older history projection/index is incomplete.

   No raw logs, prompts, project names, or local paths are attached. The fuller duplicate report is #41707.
6. LemonCANDY42 commented on Sep 4, 2026

   

   LemonCANDY42

   on Sep 4, 2026

   More actions

   Additional macOS corroboration: duplicate ordinal stalls paginated history projection

   I am adding privacy-preserving, read-only local evidence that matches the duplicate-ordinal projection failure in #41566 and explains the visible truncated-history symptom here.

   • Current macOS Desktop bundle at inspection: 26.901.31953 (Apple Silicon).
   • The affected paginated rollout records cli_version = 0.150.0-alpha.12.2; this is its recorded writer version, not a claim that the currently installed bundle created the discontinuity.
   • The canonical rollout is valid JSONL. It begins at ordinal 0, reaches ordinal 30249, and has one observed continuity break: event_msg/token_count at ordinal 21832 is immediately followed by event_msg/thread_settings_applied with the same ordinal; the next record is task_started at 21833.
   • At exactly that byte boundary, thread_history_projection_state expects ordinal 21833, while the rollout record is ordinal 21832. Local app logs independently contain expected ordinal 21833, got 21832 twice.
   • The raw rollout contains 23 task_complete events after this discontinuity. The corresponding derived thread_turns table has only 59 rows; its highest materialized turn-start ordinal is 21049, before the break.
   • Two snapshots 25 seconds apart were unchanged: the projection still expected 21833 at a record numbered 21832, with about 95 MB of valid raw rollout remaining beyond its cursor. It did not self-heal.
   • Read-only quick_check passes for both the state and history SQLite databases. I did not alter the rollout, SQLite state, cache, or any task.

   A second independent local paginated rollout has the same token_count -> thread_settings_applied duplicate-ordinal pair at a different ordinal. I am not attaching thread IDs, prompts, paths, task names, raw logs, or rollout content. This looks like a macOS instance of the same projection barrier, rather than transcript deletion.
7. LemonCANDY42 commented on Sep 5, 2026

   

   LemonCANDY42

   on Sep 5, 2026

   More actions

   Recovery result: a derived-projection-only repair restored a second macOS thread

   I can add a privacy-preserving recovery outcome for a separate affected local paginated thread. Its recorded writer version is 0.153.3, so this symptom is not confined to the earlier 0.150.0-alpha.12.2 rollout noted above.

   Before recovery, the reader returned only one initial interrupted turn with no further page. The canonical JSONL had four task_started and three task_complete events. At the projection cursor, the stored next ordinal was N, but the record at that byte offset was a duplicated N-1 thread_settings_applied event immediately after a N-1 token_count event; later records resumed at N.

   After first making a full SQLite backup, I changed only the derived thread_history_projection_state byte cursor to skip that single already-duplicated metadata record, while leaving its expected next ordinal unchanged. I did not change the canonical rollout, prompts, task data, cache, or state database. The materializer then advanced to the rollout EOF.

   Verification after recovery:

   • the app reader returned all four turns: three completed and one genuinely interrupted;
   • the projection cursor reached the raw rollout EOF;
   • read-only SQLite quick_check passed for both the live database and the pre-repair backup.

   This is not a supported general workaround. It was appropriate only after confirming the exact expected N / encountered duplicated N-1 signature and retaining a full backup. It nevertheless shows that the missing transcript was recoverable from the canonical rollout and that a supported, guarded reindex/reconciliation command could repair affected threads without rewriting user content. This matches the failure family in #41566.
8. YihengLabs commented on Sep 8, 2026

   

   YihengLabs

   on Sep 8, 2026 – with ChatGPT Codex Connector

   More actions

   Adding a macOS reproduction that closely matches this issue.

   Environment

   • macOS 26.2
   • Apple Silicon
   • Codex CLI/runtime observed during diagnosis: 0.147.0, then updated to stable 0.153.4

   Observed behavior

   After a desktop app update/restart, seven older pinned local threads lost their visible conversation history. Three newer comparable threads still display their history normally.

   For affected threads:

   • the desktop thread reader returns zero or only the newest/current turns;
   • pagination reports no additional history (hasMore=false);
   • the original rollout JSONL files still exist and contain substantial data;
   • the affected rollout files ranged from approximately 0.97 MB to 23.4 MB.

   Read-only diagnostic evidence

   • PRAGMA quick_check and PRAGMA integrity_check both returned ok for the relevant SQLite databases.
   • codex doctor on both 0.147.0 and 0.153.4 reported:
     • rollout files are missing from the state DB
     • duplicate thread inventory entries found
   • In thread_history_1.sqlite, several affected threads had zero materialized turns and zero materialized items even though their projection state indicated that the rollout had already been consumed.
   • This suggests the projection was marked complete without materializing the durable conversation items.
   • Updating to stable 0.153.4 and restarting the desktop app did not restore the missing history.

   No raw transcripts, thread IDs, local paths, usernames, account identifiers, or private project names are included here.

   A supported, non-destructive “rebuild/reindex thread history from rollout JSONL” operation would be very helpful, especially when the source transcript and SQLite integrity checks are both healthy.
9. jide commented on Sep 13, 2026

   

   jide

   on Sep 13, 2026

   More actions

   I also have the same issue