[macOS] thread/turns/list stops at an interrupted turn while later completed turns remain in rollout JSONL

What version of the Codex App are you using (From “About Codex” dialog)?

• Desktop bundle version: 26.825.31414, build 7287 (read from the installed bundle metadata).
• Bundled runtime: codex-cli 0.150.0-alpha.12.2.
• Earlier recovery logs in this incident identify Desktop release 26.820.60940. The failure is observable with the current bundle too; this does not establish which release introduced it.

What subscription do you have?

Not included in this public report. This is a local persisted-history read/recovery problem, not an observed quota or authentication error.

What platform is your computer?

macOS 15.7.8 (build 24G824), x86_64.

What issue are you seeing?

A local Desktop thread reopens at an old interrupted turn. Later user messages, assistant replies, and completed turns appear missing from the UI, but they are still present in the same original rollout JSONL file.

This is not only a suspected renderer/scroll-position problem: a separately started bundled app-server process also returns the old interrupted turn as the newest result from thread/turns/list. The raw JSONL contains several newer task_started / task_complete pairs and their message records.

No permanent data deletion has been established. Generated workspace files also remain intact.

Observed timeline

All times below are UTC on 2026-08-28. Thread/turn IDs and message contents are redacted.

Time	Evidence
02:34:33	Raw rollout records the start of turn T0. The later Desktop recovery reports T0 as interrupted.
02:51:07–03:01:27	After a reported connection interruption and continuation, raw rollout records a new turn T1, including its completion.
03:04:08–03:15:03	Raw rollout records a further turn T2 and completion.
03:18:30–03:21:24	Raw rollout records turn T3 and completion.
03:22:00–03:22:57	Raw rollout records turn T4 and completion.
05:15:24 and 05:54:58	Desktop recovery still identifies T0 as the latest turn, despite the later persisted completed turns.

Sanitized Desktop recovery fields at 05:54:58:

maybe_resume_success
latestTurnId=<T0>
latestTurnStatus=interrupted
turnCount=5

A fresh read-only app-server probe used the same installed bundled runtime and existing local Codex home, without resuming or modifying the thread:

{"id":1,"method":"initialize","params":{"clientInfo":{"name":"readonly-history-diagnostic","version":"1.0.0"},"capabilities":{"experimentalApi":true}}}
{"method":"initialized","params":{}}
{"id":2,"method":"thread/turns/list","params":{"threadId":"<affected-thread-id>","limit":3,"sortDirection":"desc","itemsView":"notLoaded"}}

The returned data contains T0 (status: "interrupted", completedAt: null) and two turns older than T0. None of T1–T4 appears in the newest page. IDs in this description are placeholders, not real identifiers.

The app's task-history read tool also returns T0 as its newest turn, although that tool describes it as inProgress. Both read paths omit the later turns.

What steps can reproduce the bug?

Observed recovery sequence on the affected existing thread:

1. Continue an existing local Desktop thread.
2. A turn is interrupted; reconnect/reopen and continue in the same thread.
3. Complete several additional turns and verify that their message records and completion events are appended to that thread's original JSONL file.
4. Reopen the thread later.
5. Observe the visible transcript ending at the earlier interrupted turn.
6. Start a separate bundled app-server process and issue the read-only thread/turns/list request above.
7. Compare the newest returned turn against the newer completed turns actually present in the JSONL.

The affected-thread read failure was reproduced with the fresh process. A standalone synthetic reproducer has not yet been established, and a connection interruption is a timeline observation, not a proven cause.

What is the expected behavior?

• The newest-first history API should include the latest durable completed turns from the affected thread.
• Reopening the thread should restore that same latest history, not silently stop at an older interrupted checkpoint.
• If persisted history cannot be reconciled or reconstructed, the client should surface an explicit recovery/loading error rather than make later messages appear deleted.
• A supported, non-destructive repair path would be helpful if the history projection/index has diverged from the raw transcript.

Additional information

• The rollout was approximately 43 MB at the time of diagnosis.
• Raw message text and later completion events are present. The discrepancy is between persisted transcript records and the history returned by the read/recovery path.
• This narrows the problem beyond a single stale renderer, but does not prove whether the defect is in an index, cursor, persisted projection, or rollout reconstruction.
• No history edits, rollback, cache deletion, or storage repair were performed during diagnosis.
• Possibly related: #40907 (Windows history reopens at an older checkpoint). This report adds macOS environment details and a fresh app-server read that independently omits known-persisted later turns.
• #36828 describes a macOS case where server pagination succeeds; this case differs because the server's newest-turn read itself is stale.

Privacy: No raw rollout, database, complete application log, screenshot, business document, prompt text, local user path, account data, or real session/turn identifier is attached. The report contains only the redacted technical evidence above.

Start with the read-only app-server thread/turns/list entry point and compare its newest-page results with the affected thread's original rollout JSONL. Reproduce the interrupted-then-completed-turn sequence if possible, then identify why later durable turns are omitted and verify that history reopening returns the latest completed turns or reports an explicit recovery error.