Windows Codex Desktop: persisted local thread reopens with only its first turn after restart

App version

OpenAI.Codex Microsoft Store package 26.825.6671.0.

Platform

Windows desktop app, local Windows-native project. No SSH, WSL, Remote Control, or second host is involved.

Issue

A long-running local Codex Desktop chat remains present in the project sidebar after closing and reopening the app, but opening it renders only the initial user message and initial assistant response. All later messages disappear from the visible chat.

This is repeatable after a normal close/reopen and persists after updating the app.

The conversation has not been deleted: its local rollout/session JSONL remains valid and continues to receive events. For one affected thread, I observed:

• desktop thread/read / thread/turns/list exposes only one initial turn with status inProgress;
• thread metadata's updatedAt remains equal to its original createdAt;
• the raw local journal contains 523 persisted message items (91 user, 425 assistant, 7 developer), plus tool and reasoning items; its latest event is after the latest restart.

This appears to be a mismatch between the thread/index record used by the desktop UI and the persisted rollout journal. It is not sidebar filtering: the thread is visible and selectable, but its detailed view contains only turn one.

Steps to reproduce

1. Start a local Windows-native Codex Desktop chat in a saved project.
2. Continue it for many user/assistant exchanges. This happened in a chat involving tool work, though I have not isolated tools as a required cause.
3. Close the desktop app normally and reopen it.
4. Open the same still-visible chat from its project.
5. Observe only the first exchange is rendered.

Expected behavior

Every persisted turn should rehydrate in the desktop chat view after a normal restart, and stored thread metadata should advance as turns are saved.

Actual behavior

The raw journal retains the conversation, but the desktop thread API/UI behaves as though only the first, never-finished turn exists. The task becomes unusable after restart because important context is hidden.

Additional information

• No local Codex state, journal, cache, or database has been manually edited or deleted.
• I intentionally have not attached the raw journal or thread ID because it contains project context and may contain sensitive data.
• This looks related to #23999 and #26624, but differs in that the affected local Windows chat is still visible and its raw journal continues to receive events; only the turn index/rendered history is stale.
• A supported reindex or reconciliation action for a valid local rollout would be valuable.

Start by tracing the desktop thread/read and thread/turns/list entry points alongside the persisted rollout/session JSONL and thread metadata. Compare how the one-turn index and unchanged updatedAt are produced after restart; done means every persisted turn rehydrates in the chat view and thread metadata advances, with regression coverage for this restart scenario.