[Windows][Desktop 26.831.1445.0] Edited prompts reopen on an older conversation branch and hide later completed turns #42269

What version of the Codex App are you using (From “About Codex” dialog)?

26.831.1445.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

On Codex Desktop for Windows, tasks in which a previously sent prompt was edited can later reopen on an older conversation branch.

All later completed user and assistant turns disappear from the visible UI. In one affected task, the visible conversation rolled back almost to the initial prompt, even though a long conversation and many completed turns had existed after it.

The missing history still exists in the local rollout JSONL files under .codex/sessions and can be recovered by another Codex task inspecting those files. This appears to be a conversation-branch selection or resume-state bug, not permanent transcript deletion.

This has occurred in multiple unrelated local tasks.

Environment

• Codex Desktop App: 26.831.1445.0
• App-server version reported in the desktop log: 0.152.0
• Subscription: ChatGPT Pro
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Task type: Local
• Session history mode: paginated
• Session memory mode: disabled

Suspected trigger

The affected tasks had prompts that were edited after being sent.

Editing created additional rollout JSONL files with the same root session ID and history_base references to previous branches.

Some short edit branches ended with turn_aborted, while other branches contained the later conversation and successful task_complete events.

After reopening or reconnecting to the task, the Desktop app selected an older/interrupted branch instead of the branch containing the later completed conversation.

Sending many additional messages after the edited prompt did not prevent the rollback. One affected task had a very long completed conversation after the edit but still reopened almost at the initial prompt.

Steps to reproduce

The following prompts are sanitized equivalents and are not the private project prompts used in the affected tasks.

1. Create a local task in Codex Desktop for Windows.

2. Send a prompt such as:

   Continue the current task using the existing project state.

3. Use the message edit function to change the sent prompt to something such as:

   Correction: keep the existing project state, but change requirement X to Y.

4. Continue the conversation for multiple user and assistant turns.

5. Wait for the subsequent turns to complete successfully.

6. Switch to another task, reconnect to the task, or restart the Desktop app.

7. Reopen the affected task.

Actual behavior

The task may reopen on an older conversation branch or almost at the initial prompt.

Later completed turns are not visible anywhere in the UI, and scrolling does not reveal them.

The task may also appear to be interrupted or still streaming even though the branch containing the later work has completed.

There is no warning that the visible transcript is stale or that another branch containing later completed turns exists.

Expected behavior

After editing a sent prompt, the edited branch and all later completed turns should remain the selected, visible branch after switching tasks, reconnecting, or restarting the app.

If multiple branches exist, the app should either:

• restore the branch most recently used and completed;
• provide a branch selector or recovery UI; or
• display an explicit reconciliation error instead of silently showing an older transcript.

Local forensic evidence

The local transcript data was not deleted.

For the affected tasks:

• Multiple rollout JSONL files have the same root session ID.
• Edited branches contain history_base metadata.
• Some edit attempts end with turn_aborted.
• Other branch files contain the missing later conversation and task_complete.
• The affected session metadata reports memory_mode: disabled.
• The completed branch files remain parseable.

A Desktop log recorded the following inconsistent resume state:

maybe_resume_success ... latestTurnStatus=interrupted ... markedStreaming=true

The app therefore recognized the latest selected turn as interrupted while simultaneously restoring the task as streaming.

This appears consistent with the stale “Continue” state shown in the UI.

Ordinal verification

I checked the affected completed rollout files for non-consecutive or duplicate top-level ordinals.

No ordinal discontinuities were found in the inspected completed branches.

Therefore this does not appear to be the same failure as the duplicate-ordinal projection bug reported in #41566.

Transcript sizes

The issue is not limited to one transcript size:

• One affected completed branch was approximately 22 MB with 4,884 records.
• Another image/tool-heavy affected task had branches of approximately 400–540 MB.
• Both the smaller and larger tasks exhibited the visible branch rollback.

Large transcripts may amplify the loading problem, but they are not the sole trigger.

In-app feedback result

In-app feedback was submitted from one affected task.

The feedback text was accepted, but its attachments failed to upload twice with the full error:

failed to upload feedback: feedback report was accepted, but some attachments failed to upload

The corresponding Desktop log recorded:

• method: feedback/upload
• error code: -32603

Because the affected transcript branches are very large and contain private project data, I am not attaching the raw JSONL files publicly.

I can provide sanitized branch metadata and relevant log excerpts privately if needed.

Impact

This makes long-running Codex tasks unreliable as durable project records.

Users may believe that days of conversation, decisions, and completed work have been deleted. Continuing from the stale branch can also cause duplicated work or decisions based on outdated context.

A supported branch recovery/reindex mechanism is needed even after the underlying selection bug is fixed.

Related issues found before filing

These issues have similar symptoms, but none documents the same edited-prompt branch trigger together with the evidence above:

• [Windows][Work] Reopening a thread restores an older checkpoint and hides later conversation turns #40907 — Reopening a thread restores an older checkpoint and hides later turns
• Windows Desktop: conversations disappear from UI even though JSONL sessions still exist; add first-party recovery/reindex tool #40779 — Conversations disappear from the UI although JSONL sessions still exist
• Codex desktop thread history is not persisted and task remains permanently in progress #41864 — Thread history is missing and the task remains in progress
• Codex paginated rollout can emit duplicate ordinal after unfinished turn, permanently freezing thread history projection #41566 — Paginated rollout freezes after duplicate ordinals

This report differs from #41566 because no duplicate ordinals were found in the inspected affected rollouts.

What steps can reproduce the bug?

No repository code snippet is required or applicable because this is a Codex Desktop conversation-history and branch-restoration bug.

The following is the smallest UI reproduction I can currently provide.

Reproduction steps

1. Open Codex Desktop for Windows.
2. Create or open a local task.
3. Send a prompt.

Sanitized equivalent prompt:

Continue the current task using the existing project state.

4. Use the Edit action on the previously sent prompt.

Sanitized equivalent edited prompt:

Correction: preserve the existing project state, but change requirement X to Y.

5. Continue working in the edited conversation for multiple turns.
6. Wait until the later assistant turns complete successfully.
7. Switch to another task, close and reopen the affected task, reconnect to the local host, or restart Codex Desktop.
8. Open the affected task again.

Actual result

The app may restore an older conversation branch, sometimes almost back to the initial prompt.

Later completed user and assistant turns are no longer visible in the UI, even though they remain present in the local rollout JSONL files.

Sending additional messages after the edited prompt does not reliably prevent the rollback. One affected task had a long sequence of completed turns after the edit and still reopened almost at the initial prompt.

Affected session IDs

Session 1:

01a03b8f-2b6f-7242-b0ac-96e19ab86826

Session 2:

01a04fa1-b91f-78e2-9054-d17e0dcd73f7

Token and context-window information

Session 1:

• Model context window: 258,400 tokens
• Last recorded turn usage: 111,402 / 258,400 tokens, approximately 43.1%
• Cumulative token usage recorded for the inspected completed branch: 91,365,072
• Rate-limit usage at the final recorded event: 12%
• No rate limit was reported as reached

Session 2, first inspected completed branch:

• Model context window: 258,400 tokens
• Last recorded turn usage: 124,976 / 258,400 tokens, approximately 48.4%
• Cumulative token usage recorded for that branch: 183,030,331
• No rate limit was reported as reached

Session 2, later inspected completed branch:

• Model context window: 258,400 tokens
• Last recorded turn usage: 198,534 / 258,400 tokens, approximately 76.8%
• Cumulative token usage recorded for that branch: 46,076,628
• No rate limit was reported as reached

The rollback therefore occurred without the last recorded turn necessarily exhausting the model context window.

What is the expected behavior?

After a sent prompt is edited, Codex Desktop should preserve the edited conversation branch as the active branch.

When the task is reopened, reconnected, or restored after an application restart:

• The most recently used edited branch should remain selected.
• All subsequent completed user and assistant turns should remain visible.
• A completed branch must not be replaced in the UI by an older interrupted branch.
• The task status should accurately show whether the latest turn is completed, interrupted, or running.
• The Send button should not incorrectly become a Continue button because an older interrupted turn was restored.
• Switching between tasks must not change which conversation branch is considered current.

If the application cannot determine which branch should be restored, it should show an explicit reconciliation error or provide a branch/recovery selector. It should not silently display an older transcript as though it were the complete conversation.

The local rollout JSONL files containing later completed turns should be treated as recoverable conversation data and should be reindexed or displayed through a supported recovery mechanism.

Additional information

Local evidence

This does not appear to be permanent transcript deletion.

The later conversation remains in local rollout JSONL files under .codex/sessions. Another Codex task can inspect those files and recover the missing conversation.

The affected sessions have:

• history_mode: paginated
• memory_mode: disabled
• Multiple rollout JSONL files sharing the same root session ID
• Edited branches containing history_base references
• Some short edited branches ending with turn_aborted
• Other branches containing the missing later conversation and successful task_complete events

This indicates that the Desktop app is restoring or projecting the wrong conversation branch.

Resume-state inconsistency

The Codex Desktop log recorded the following state during resume:

maybe_resume_success ... latestTurnStatus=interrupted ... markedStreaming=true

The app therefore recognized the selected turn as interrupted while simultaneously restoring the task as streaming.

This appears consistent with the stale Continue state and the older branch displayed in the UI.

Ordinal verification

The completed rollout files were checked for duplicate or non-consecutive top-level ordinals.

No ordinal discontinuities were found in the inspected affected branches.

This therefore does not appear to be the same cause as the duplicate-ordinal projection problem described in #41566.

Transcript sizes

The problem occurred with different transcript sizes:

• One affected completed branch was approximately 22 MB and contained 4,884 records.
• Another affected task had image/tool-heavy transcript branches of approximately 400–540 MB.
• Both the smaller and larger tasks experienced visible history rollback.

Large transcript size may amplify the problem, but it is not the sole cause.

In-app feedback upload

In-app feedback was submitted from one affected task. The feedback report text was accepted, but the attachments failed to upload twice.

Full error message:

failed to upload feedback: feedback report was accepted, but some attachments failed to upload

Related log fields:

method=feedback/upload
errorCode=-32603

The raw transcripts are not attached to this public issue because they contain private project content, prompts, command outputs, and local filesystem paths.

Sanitized branch metadata and targeted log excerpts can be provided privately if needed.

Related issues

The following issues have similar symptoms, but I did not find an exact report combining the edited-prompt branch trigger with the evidence above:

• [Windows][Work] Reopening a thread restores an older checkpoint and hides later conversation turns #40907
• Windows Desktop: conversations disappear from UI even though JSONL sessions still exist; add first-party recovery/reindex tool #40779
• Codex desktop thread history is not persisted and task remains permanently in progress #41864
• Codex paginated rollout can emit duplicate ordinal after unfinished turn, permanently freezing thread history projection #41566

The affected completed rollouts in this report do not contain the duplicate ordinal described in #41566.