[Windows Desktop + Mobile Remote] newest history page repeatedly regresses to previous-day boundary while a 2.27 GB rollout keeps growing

Summary

A long-running local Codex task on Windows repeatedly shows a stale previous-day conversation on the phone while the task continues accepting new messages and working on the host. A read-only history query reproduced the exact stale message boundary described by the user.

This report does not claim transcript deletion or a confirmed duplicate-ordinal root cause.

Environment

• Windows desktop package: OpenAI.Codex 26.901.6511.0
• Incident: 2026-09-07, approximately 23:28–23:44 Europe/Warsaw (UTC+02:00)
• Remote client: phone; mobile OS and app version were not captured in this diagnostic
• Long-running local task, active since September 5
• Canonical rollout JSONL size at 21:41:19 UTC: 2,266,381,154 bytes (about 2.27 GB)
• The separately installed npm CLI reports 0.130.0; this is NOT asserted to be the desktop app's bundled runtime version.

Observed sequence

1. The user reported that the phone view stopped at a particular assistant message from the previous day.
2. A read-only list_threads call reported the task as active with a current updatedAt timestamp.
3. A read_thread call with turnLimit=1, includeOutputs=false and maxOutputCharsPerItem=600 returned a page marked newest_first, but its latest returned turn started on the previous day and its final visible assistant message matched exactly the old boundary identified by the user.
4. The returned turn was marked inProgress, contained 100 items and returned hasMore=true with a nextCursor whose rolloutOrdinal was 11878.
5. The canonical local JSONL was still being appended to. A bounded tail check parsed the latest records successfully and showed timestamps from the current working session. This was not a full validation of the multi-gigabyte transcript.
6. The user temporarily saw the newer conversation again after these read-only checks. No app restart, database change, deletion, cache clear, or history rewrite had been performed.
7. The phone view subsequently became stale again during the same working session.

The timing of temporary recovery is recorded as correlation only: we cannot establish that querying history caused it.

Expected behavior

• Remote and paginated history readers should return a bounded, current tail of an active task.
• A history view should not silently present a previous-day boundary as the newest page while newer durable activity exists.
• If projection or hydration cannot catch up, surface a recoverable error and retain the canonical history.
• Provide a supported non-destructive repair or reindex path.

Areas to investigate, not confirmed causes

History projection/cache cursor consistency, pagination of very large rollouts, and remote hydration/reconciliation. The large file size may be relevant, but no size-limit or ordinal-corruption diagnosis has been established.

Possibly related: #41079, #43434 and #38023. Unlike the confirmed duplicate-ordinal report, no duplicate ordinal has been verified in this incident.

Work preservation and privacy

The user requested a new short continuation task in the same local workspace as a workaround. Existing project files and the old conversation are being retained.

No account identifiers, task IDs, task titles, local usernames/paths, project content, images, credentials, or raw transcript/log files are included in this report.

Start by reproducing the read-only list_threads and read_thread calls against a large, active rollout. Investigate history projection/cache cursor consistency, pagination, and remote hydration or reconciliation, using the reported previous-day boundary and nextCursor rolloutOrdinal 11878 as markers. Done means the newest page returns the current bounded tail, or a recoverable error preserves canonical history and exposes a non-destructive repair path.