[Windows Desktop + Mobile Remote] history reconstructs to the same stale checkpoint previously seen on Remote; intermediate days disappear after restart

Summary

A long-running local Codex Desktop thread on Windows has now shown a cross-device history/reconstruction failure with a particularly suspicious timeline:

• Codex Mobile Remote first rolled back to an older checkpoint while the Windows Desktop thread continued normally with newer history.
• The Windows machine was later fully rebooted, and Codex Desktop successfully cold-restored the complete newer conversation history beyond that checkpoint.
• Several days later, multiple local Codex conversations began failing to reconstruct in Desktop.
• After fully quitting and restarting Codex Desktop, the most important thread reopened with approximately a week of intermediate conversation/tool history missing, while the newest active turn was still visible.
• The older visible history now stops at the same checkpoint that Mobile Remote had previously rolled back to.

This report intentionally does not claim that the underlying rollout data has been physically deleted. A read-only local forensic inspection has not yet been completed. The purpose of this report is to preserve the observed timeline before attempting any repair.

Environment

• Product: Codex Desktop + Codex Mobile Remote
• Desktop OS: Windows
• Subscription: ChatGPT Pro
• Desktop app / bundled Codex version: not yet captured
• Incident date: 2026-09-07
• Timezone of reporter: Asia/Bangkok (UTC+07:00)
• The affected Desktop machine is physically located in Beijing and was observed remotely by video call during the incident.

Observed timeline

~September 2, 2026 — Mobile Remote rollback

A long-running local Windows Codex Desktop thread continued executing normally.

On the iPhone Codex Remote view, later USER / TOOL / FINAL history had already been visible. While Remote remained in use, its displayed conversation later rolled back to an older checkpoint (referred to below as checkpoint X).

At that time:

• Windows Desktop did not roll back.
• The Desktop thread continued forward.
• Later history remained visible on Desktop.

September 3, 2026 — full Windows reboot proves later history was recoverable after cold start

The Windows PC was fully rebooted for an unrelated Docker startup problem.

This was a real machine reboot, not merely a renderer refresh or Codex window reopen.

After reboot:

• Codex Desktop was started again.
• Docker was started again.
• The same important Codex thread reopened normally.
• The conversation history beyond checkpoint X was still present and usable.
• Work continued for several more days.

This appears important because it rules out a simple explanation where Desktop only appeared correct because newer history existed solely in process memory and had never survived a cold restart.

September 7, 2026 — Desktop reconstruction failure

Around early afternoon, Mobile Remote again stopped updating / lost connection to the Beijing Desktop session.

The Windows Desktop screen was inspected by live video call. The active Codex task appeared visually unchanged for several hours; the bottom-most visible status/output line had not changed.

To determine whether only that task was stuck, several other local Codex projects/conversations were opened.

At that point, multiple different conversations showed the same failure pattern:

• A red warning repeatedly appeared at the top of the window.
• In the Chinese UI the warning was observed as approximately “无法重建会话” (roughly “unable to reconstruct conversation”).
• The warning appeared briefly, disappeared, and immediately reappeared in a loop.
• The center of the window showed a rename-conversation UI.
• Choosing either save or cancel did not make the affected conversation content render normally.
• The same general behavior occurred across multiple local Codex conversations, not only the important thread.

Because the failure already affected multiple conversations, no repair/reset/reindex operation was attempted.

Codex Desktop was then fully exited from the Windows system tray and started again.

After the September 7 restart

The important thread could be opened again, but its reconstructed history was abnormal:

• The newest active turn was still visible. That turn involved Codex obtaining a task from a GPT conversation and beginning execution.
• Above that newest turn, approximately a week of intermediate conversation / tool / result history was no longer visible.
• The older visible history stopped at exactly the same checkpoint X that Mobile Remote had previously rolled back to days earlier.

Observed shape:

Before:
checkpoint X
  -> several days / roughly a week of later conversation, tools, results
  -> newest active turn

After restart:
checkpoint X
  -> [intermediate history not visible]
  -> newest active turn still visible

The exact local persistence state has not yet been inspected, so this report does not assume whether the missing middle section is absent from the canonical rollout, present but not projected, or associated with another lineage/branch.

Why the timeline seems significant

The September 3 full Windows reboot successfully restored all then-current history beyond checkpoint X.

Therefore, a simple model such as:

“newer history only survived in app memory until the first restart”

is inconsistent with the observed timeline.

Likewise, the fact that Desktop on September 7 reconstructed to the same older checkpoint previously seen on Mobile Remote seems worth investigating as a possible shared checkpoint / lineage / projection / resume-state boundary rather than random file truncation.

This is only an observation, not a claimed root cause.

Steps to reproduce

There is not yet a deterministic minimal reproduction. The observed sequence was:

1. Maintain a long-running local Codex Desktop thread on Windows for multiple days.
2. Use Codex Mobile Remote with that Desktop session.
3. Observe Mobile Remote displaying newer turns and later reverting to an older checkpoint X while Desktop remains current.
4. Fully reboot Windows on a later day.
5. Reopen Codex Desktop and confirm the same thread still restores the complete newer history beyond X.
6. Continue working in the same thread for several more days.
7. Later encounter a state where multiple Desktop conversations fail to reconstruct and repeatedly show a conversation reconstruction error.
8. Fully quit and restart Codex Desktop.
9. Reopen the important thread.
10. Observe that intermediate days of visible history are missing, while the reconstructed older history stops at the same checkpoint X previously seen on Mobile Remote and the newest active turn may still be visible.

Expected behavior

• A local Desktop thread that has durably survived a full Windows reboot should continue to reconstruct all supported later conversation history on subsequent restarts.
• Mobile Remote should not regress to an older conversation state after newer turns have already been displayed.
• Desktop and Mobile Remote should not independently reconstruct the same thread to a stale historical checkpoint while later durable work exists.
• If conversation reconstruction cannot complete, the app should report a precise actionable error and must not silently present a stale partial history as authoritative.
• There should be a supported, non-destructive way to verify/rebuild the derived history state from the canonical local rollout when possible.

Current handling / evidence preservation

No destructive repair has been attempted after the incident:

• no .codex deletion
• no state database deletion
• no cache reset
• no forced reindex
• no thread rollback/revert
• no archive/delete operation
• no reinstall/update performed specifically to repair this incident
• no raw transcript or private project data uploaded publicly

The next planned step is a read-only forensic preservation and comparison of the local Codex state (rollout/session files, history/state databases, and logs) to determine whether the missing intermediate history still exists in canonical local records and where reconstruction diverges.

Sanitized metadata, relevant event windows, hashes, projection cursor information, and log excerpts can be added if maintainers request them or once the read-only inspection is complete.

Related reports

Potentially related, but this report adds the cross-device same-checkpoint behavior and the September 3 successful full cold reboot before the later failure:

• #42197 — Windows Desktop history projection stuck after Remote Control session
• #41079 — Windows paginated thread history stalls while rollout remains complete
• #43182 — existing task loses access to days of history after reopen; stale projection / rollout boundary evidence
• #41566 — duplicate ordinal can freeze thread history projection

I am not claiming these have the same root cause; they are listed because the visible failure family is similar.

Begin with a read-only preservation of the local rollout/session files, history/state databases, and logs. Compare the canonical local rollout with reconstructed history around checkpoint X, using projection cursor metadata and related reports #42197, #41079, #43182, and #41566. Done means determining whether the intermediate history remains locally and where reconstruction diverges without destructive repair.