›_ Codex Issues
Codex Issues / #40452

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

Open 💬 2 comments Opened Aug 24, 2026 by simla-com
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

Codex Desktop App on Windows 11, signed in through a ChatGPT account.

Summary

After a recent Desktop App update, previously completed tasks can open with only their first user message and a partial initial assistant response. The displayed turn is marked interrupted and no further history is available.

This is not lost rollout data: the canonical local JSONL for the same task contains the full completed conversation and tool activity.

Reproduction pattern

  1. Use Codex Desktop for a multi-turn task, including tool use and delegated tasks.
  2. Let the task complete or continue it across several turns.
  3. Update/restart Codex Desktop.
  4. Reopen the existing task.
  5. Observe that the UI shows only the initial turn as interrupted; there is no available older/newer page.

Observed on two independent tasks.

Expected behavior

Completed tasks should display their complete historical turns after a Desktop App update or restart.

Actual behavior

The Desktop UI / thread reader returns only the first fragment of the conversation:

  • first user message;
  • partial first assistant message;
  • turn status interrupted;
  • no additional history (hasMore=false).

Local evidence (redacted and aggregate-only)

For two affected Desktop tasks, the corresponding canonical rollout JSONL files parse cleanly and contain:

  • task A: 18 user messages, 42 assistant messages, 15 completed turns;
  • task B: 13 user messages, 67 assistant messages, 9 completed turns.

Both affected threads use history_mode=paginated. A comparable unaffected current Desktop thread uses legacy history. The primary local SQLite state passes integrity checks, and its rollout paths/timestamps match the complete JSONL files.

No raw prompts, credentials, project names, local paths, or thread IDs are included here.

Related issue

This looks like the Desktop/App manifestation of openai/codex#37577, which reports the same completed-rollout-to-interrupted reconstruction failure through CLI resume/app-server. The difference here is that it is visible directly in Codex Desktop UI after an update.

User feedback: Linux and Remote also show truncated paginated history

  • Source: [https://github.com/openai/codex/issues/40342](<https://github.com/openai/codex/issues/40342>)
  • Source: [https://github.com/openai/codex/issues/40342#issuecomment-5393483353](<https://github.com/openai/codex/issues/40342#issuecomment-5393483353>)
  • Source: [https://github.com/openai/codex/issues/40342#issuecomment-5409222951](<https://github.com/openai/codex/issues/40342#issuecomment-5409222951>)
  • Source: [https://github.com/openai/codex/issues/40342#issuecomment-5409937838](<https://github.com/openai/codex/issues/40342#issuecomment-5409937838>)
  • Type: external
  • User reports:
  • “Reproduces across Linux Desktop, laptop Remote, and mobile Remote.”
  • “the Desktop/thread reader returns only one interrupted turn and reports no additional page” while the rollout contains later completed turns.
  • On a remote Ubuntu 24.04 host, “24/24 paginated-history threads have incomplete projections” and “The affected rollout files remain present and valid.”

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 days ago

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

  • #40342

Powered by Codex Action

someone114514 · 1 day ago

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.