Repository navigation
[Windows Desktop + Mobile Remote] newest history page repeatedly regresses to previous-day boundary while a 2.27 GB rollout keeps growing #43600
Description
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
- The user reported that the phone view stopped at a particular assistant message from the previous day.
- A read-only list_threads call reported the task as active with a current updatedAt timestamp.
- 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.
- The returned turn was marked inProgress, contained 100 items and returned hasMore=true with a nextCursor whose rolloutOrdinal was 11878.
- 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.
- 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.
- 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.
Activity
github-actions commentedon Sep 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
diegocantarero commentedon Sep 12, 2026
Additional cross-platform reproduction on macOS host, observed 2026-09-12.
Environment:
Observed:
This looks like newest-page hydration/projection divergence on an oversized rollout, not physical transcript deletion and not an Android-only client cache issue. No raw transcript, local paths, account identifiers, or full task IDs are included here. I can provide sanitized timestamps/item suffixes privately if maintainers need correlation.
Expected: Remote should hydrate the canonical newest completed page, or return a typed oversized-thread/reindex error rather than silently serving an older boundary.
diegocantarero commentedon Sep 12, 2026
Follow-up protocol correlation from the same macOS reproduction:
A bounded read-only query over the newest 200,000 host log rows shows that the iOS Remote client is not merely offline. Recent activity includes 10 iOS-remote client events, 21 thread/list events, 19 thread/read events, and 93 thread/resume events. The affected oversized task itself received a recent thread/resume.
Despite those requests, both supported host read projection and mobile Remote still stop at yesterday while the canonical rollout contains completed final answers from today. The affected task also produced 346 WARN events from codex_thread_store::local::live_writer in the same bounded window.
This narrows the failure to newest-page projection/hydration after request dispatch, potentially amplified by the active live-writer state and rollout size. It is not evidence of network disconnection or physical transcript deletion. No raw log bodies, paths, account data, or task IDs are included.
victorllee commentedon Sep 14, 2026
Additional independent Windows + phone Remote report (September 13, 2026 local time)
Posting with the affected user's explicit request to report this to OpenAI. This appears related to this issue, but a common root cause has not been established.
User observation
Independent read-only evidence
list_threadsreturned the same local task with a currentupdatedAttimestamp and active status.read_threadfor that exact task, withturnLimit: 6andincludeOutputs: false, returned a page advertised asnewest_first.startedAt: 1788944582(2026-09-09 09:03:02 UTC),status: inProgress, andcompletedAt: null. The other returned turns were older.Expected
Remote and history retrieval should reflect the latest supported state of the same conversation, or clearly report that history reconstruction is incomplete. Stale execution metadata must not silently be presented as the current run.
Impact and handling
The user cannot reliably continue the same task from the phone. Old progress appearing active also creates concern about accidentally resuming superseded instructions. This report does not establish that old operations actually executed, that files were damaged, or that transcript records were deleted.
No cache reset, state-database rewrite, transcript deletion, thread rollback or application restart was attempted as a repair. The old retrieved instructions were not executed. Previously stopped scheduled work was not restarted.
Environment: Windows desktop and phone Remote; exact app builds and phone OS were not captured. No thread/account IDs, project names, repository URLs, local paths, server addresses, credentials, screenshots, raw transcripts or diagnostic logs are included in this public report.