Skip to content

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

Open
Open
[Windows][Work] Reopening a thread restores an older checkpoint and hides later conversation turns#40907
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

Description

@BananaMeow-del
BananaMeow-del
opened on Aug 26, 2026

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:

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

Activity

  1. BananaMeow-del commented on Aug 26, 2026

    @BananaMeow-del
    BananaMeow-del
    on Aug 26, 2026 – with ChatGPT Codex Connector
    Author

    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.

  2. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Aug 26, 2026

  3. BananaMeow-del commented on Aug 26, 2026

    @BananaMeow-del
    BananaMeow-del
    on Aug 26, 2026 – with ChatGPT Codex Connector
    Author

    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.

  4. github-actions commented on Aug 26, 2026

    @github-actions
    github-actionsBot
    on Aug 26, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  5. znbsf commented on Sep 2, 2026

    @znbsf
    znbsf
    on Sep 2, 2026

    I am seeing the same issue on Windows.

    Environment

    • Codex Desktop package: 26.831.1445.0
    • OS: Windows 10 Pro 10.0.19043 x64
    • Observed: 2026-09-02
    • Long-running local Work thread; full thread ID withheld because the transcript contains private source paths and project context.

    Observed behavior

    • Reopening the thread restores an older visible checkpoint. In my case, the last visible work is from Aug 31.
    • The complete Sep 1 user/assistant activity is absent from the GUI.
    • New Sep 2 messages are appended below that older checkpoint, making the transcript look as if it rolled back and then resumed from stale history.
    • Scrolling does not reveal the missing Sep 1 block.

    Local evidence

    • The canonical rollout JSONL still exists, is about 129 MB, and continued to be modified on Sep 2.
    • The Sep 1 portion contains 5,835 persisted JSONL records, including 24 user messages, 114 assistant messages, 857 tool calls, 873 tool outputs, and 8 compaction-related records.
    • Desktop logs show thread/read, thread/resume, thread/turns/list, and repeated thread/items/list requests completing with errorCode=null; resume is reported as successful, but the rendered transcript remains incomplete.
    • Repository/files produced by the missing turns are also still present, so this is not evidence of workspace rollback.

    This looks like a visible-history rollback / stale checkpoint, pagination, or thread rehydration problem rather than confirmed canonical transcript deletion. I am not attaching the screenshot or raw transcript because both contain private local/project information, but I can provide a sanitized feedback ID or more aggregate diagnostics if maintainers need them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions