macOS: newest-first thread lookup returns two-day-old in-progress turn despite newer persisted messages

Recent conversation lookup returns two-day-old turns while newer messages remain in the local transcript

Environment

• Observed September 5, 2026, around 8:33 PM America/New_York (September 6, 00:33 UTC).
• macOS 26.5.2, arm64.
• Long-running local Codex conversation spanning multiple days.
• Installed desktop/build version was not established. The documented compatibility bundle path was absent; no version is inferred.

User-visible symptom

The user reports that substantial recent conversation history disappeared from the displayed chat and that the conversation appears to have reverted approximately two days. The UI symptom is user-reported; the retrieval mismatch below was independently observed.

Independently verified evidence

1. Read the affected thread using the available read_thread app tool with includeOutputs: false, without a pagination cursor.
2. A request for the newest eight turns returned old September 3 work. Repeating with turnLimit: 2 returned the same old newest turn.
3. The second response declared page.order: newest_first, page.limit: 2, and hasMore: true.
4. Its newest returned turn had startedAt: 1788468606 (September 3, 2026, 20:50:06 UTC), status: inProgress, and completedAt: null.
5. The thread metadata was current: updatedAt: 1788654804 (September 6, 2026, 00:33:24 UTC), despite returning a September 3 turn as newest.
6. A read-only inspection of the matching local session JSONL file found newer user/assistant message records dated September 6 at 00:32:32, 00:33:06 and 00:33:08 UTC, including the user's current report. The file was approximately 147 MiB at inspection.
7. Independently, the working repository retained the latest same-evening committed work. This is not evidence of a repository rollback.

Expected behavior

The current conversation view and a cursor-free newest-first thread lookup should expose the latest persisted messages, with consistent turn status and ordering. Pagination should not silently make a multi-day-old turn appear to be the latest available work.

Actual behavior and impact

The newest-first lookup is inconsistent with current thread metadata and recent persisted messages. The visible chat reportedly loses approximately two days of history. This undermines confidence in completed work and could cause an operator or agent to repeat already completed actions based on stale history.

Reproduction limits / hypotheses

• Confirmed twice against one affected existing thread; no minimal synthetic reproduction yet.
• Recent sampled messages are present on disk. Completeness of every intervening message has not been audited, so this report does not claim universal absence of data loss.
• A stale index, incorrect pagination boundary, or turn reconstruction problem is a working hypothesis, not a proven cause.
• No cache deletion, transcript rewrite, database mutation, restart, or recovery action was performed during diagnosis.

Requested investigation

Please investigate how the desktop conversation view and read_thread newest-first pagination reconstruct long-running turns from persisted session records, particularly when an old turn remains marked in progress despite newer records and current thread metadata.

Related reports

• #43124 describes a similar macOS stale-history symptom with a verified projection ordinal mismatch. This report has not inspected projection ordinals and does not claim that cause.
• #41079 describes Windows paginated history stalling while the rollout remains complete.
• #42971 describes recent metadata with an older in-progress turn after account switching on Windows. No account-switch trigger has been established in this case.

Privacy

No raw transcript, screenshots, log attachments, conversation text, thread/session identifiers, project/repository names, hostnames, local account paths, credentials, tokens, URLs from captured activity, or production data are included. This report contains only a manually selected symptom description, software environment and diagnostic timing/status metadata.

Start with the read_thread app tool and the matching local session JSONL file, then trace how the desktop conversation view reconstructs newest-first pagination from persisted records. Compare thread metadata, turn status, timestamps, and ordering; done means a cursor-free lookup exposes the latest persisted messages consistently without presenting the old in-progress turn as newest.