[Windows][Work] Reopening a thread restores an older checkpoint and hides later conversation turns

Open 💬 3 comments Opened Aug 26, 2026 by BananaMeow-del
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Exact app/package version was not captured yet. Observed in the current Windows ChatGPT/Codex Desktop app on 2026-08-27.

What subscription do you have?

Paid ChatGPT account; exact tier not included in this public report.

What platform is your computer?

Windows desktop; exact Windows build not captured yet.

What issue are you seeing?

Summary

A long-running ChatGPT Work thread repeatedly reopens at the same older task/checkpoint even though the conversation continued beyond that point.

Later user and assistant turns definitely existed after the checkpoint, but after leaving the thread and returning to it, those later turns are no longer visible. The thread appears to have rolled back to an older visible state without any warning or recovery option.

This is more serious than restoring the wrong scroll position: the later conversation content cannot be reached by scrolling because the visible transcript ends at the stale checkpoint.

I am intentionally describing this as a visible history rollback / thread rehydration failure rather than confirmed permanent data deletion. It has not yet been verified whether the canonical rollout/history still contains the missing turns.

Actual behavior

  • The Work thread is used normally and receives additional turns after a specific earlier checkpoint.
  • After switching away from the thread, closing/reopening the app, or later returning to the thread, the UI repeatedly restores the same older checkpoint.
  • Later turns that previously existed are absent from the visible transcript.
  • The UI provides no warning that history hydration is incomplete or stale.
  • Returning to the thread again reproduces the same rollback point.

In the captured reproduction, the affected Work thread also displayed a stale Thinking state near that older checkpoint, but the main defect is the missing later transcript after reopening.

Steps to reproduce

  1. Open a long-running ChatGPT Work thread in the Windows desktop app.
  2. Continue the conversation for multiple user/assistant turns beyond an earlier assistant/tool-activity checkpoint.
  3. Switch to another thread or project, or close and reopen the desktop app.
  4. Return to the affected Work thread.
  5. Observe that the thread opens at the same older checkpoint.
  6. Scroll to the bottom and verify that the later turns that previously existed are no longer present.
  7. Leave and reopen the thread again; the same older visible state is restored.

The problem occurs repeatedly on the affected thread rather than as a one-time rendering glitch.

Expected behavior

  • Reopening a Work thread should hydrate the latest durable thread history.
  • Every previously persisted user and assistant turn should remain visible.
  • The app should restore the latest conversation state, not an older projection or checkpoint.
  • If history hydration or reconciliation fails, the UI should show an explicit loading/recovery error rather than silently displaying a truncated transcript.
  • The product should provide a supported repair/reindex path if the visible history projection diverges from the canonical thread data.

Impact

This makes a long-running Work thread unreliable as a project record:

  • later decisions, analysis, and task results appear lost;
  • the user cannot safely continue from the latest work;
  • work may be duplicated because the visible transcript is stale;
  • the user cannot tell whether the missing content still exists in canonical storage;
  • trust in Work as a persistent project workspace is significantly reduced.

Diagnostic request

Please compare, for the affected thread:

  • the canonical rollout/thread history;
  • the Desktop Work UI history projection;
  • any paginated-history or checkpoint cursor used on resume;
  • the latest durable turn versus the latest turn returned to the renderer;
  • renderer/app-server rehydration logs when the thread is reopened.

A privacy-scrubbed screenshot is available. The exact thread ID, app version, and an in-app /feedback ID can be supplied privately once captured.

Related issue

Possibly related, but not necessarily a duplicate:

  • #17354 — Recent thread history is missing in the GUI while still present in the CLI.

This report is specifically a repeatedly reproducible Windows ChatGPT Work thread that reopens at one older checkpoint and hides all later visible turns.

View original on GitHub ↗

3 Comments

BananaMeow-del · 1 day ago

Further investigation suggests this is likely part of the same paginated-history projection failure family as #40342 and #38792, with the Windows stale-checkpoint symptom also overlapping #40336.

The strongest current hypothesis is:

  1. The canonical rollout continues to contain turns written after the visible cutoff.
  2. The derived paginated history projection stops advancing at or near a structured token_count record.
  3. thread_history_projection_state.next_rollout_byte_offset and next_rollout_ordinal diverge, so later valid rollout records are never materialized into thread_items / thread_turns.
  4. Reopening the Work thread therefore returns the same stale projected tail every time, while the UI can also retain a stale Thinking / inProgress state because the later completion record was never projected.

This would explain the key symptoms in this Windows Work reproduction: an identical cutoff after every reopen, later turns no longer reachable by scrolling, and a stale Thinking indicator at the cutoff.

This is not yet confirmed for the private affected thread because its rollout, projection DB rows, app version, and logs have not been inspected. Please check:

  • whether the thread uses history_mode=paginated;
  • whether the durable rollout has records after the UI cutoff;
  • the projection cursor byte offset and expected ordinal;
  • whether the cutoff or preceding record is event_msg/token_count with structured rate-limit data;
  • whether thread/read or thread/turns/list incorrectly returns hasMore: false;
  • logs for invalid type: map, expected f64 or expected ordinal N, got N+1.

The user has not modified the local SQLite databases or rollout files. A supported automatic re-projection/repair path is needed; manual DB editing is not an acceptable user recovery workflow.

BananaMeow-del · 1 day ago

Additional privacy-scrubbed recurrence on the same Windows Work thread:

  • The conversation continued beyond the Desktop-visible cutoff.
  • ChatGPT iOS Remote displayed the later user/assistant turns and the completed result.
  • After returning to Windows Desktop, those same later turns and the completed result were absent; Desktop again ended at the earlier stale checkpoint.
  • This was not a failed model run or an unsent message: the result was visibly completed on another client before it disappeared from the Desktop view.

This is strong cross-surface evidence that the thread's newer state exists outside the stale Windows Desktop projection. It points to Desktop resume/history hydration returning an older projected tail rather than permanent model-output loss.

Please compare the same thread across surfaces:

  • latest durable/canonical turn;
  • iOS Remote thread/read / live state;
  • Windows Desktop thread/read and thread/turns/list responses;
  • hasMore / pagination cursors;
  • thread_history_projection_state byte offset and ordinal;
  • latest projected turn status versus the durable task_complete record.

The raw screenshot was intentionally not uploaded because it contains private project names, filenames, business content, and conversation text. No thread ID, account ID, host/device identifier, project name, filename, prompt text, or result content is included in this public update.

github-actions[bot] contributor · 1 day ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #40336
  • #40609
  • #40112
  • #40452
  • #40522

Powered by Codex Action