Later conversation turns become incorrectly collapsed under an earlier “Continue” turn after interruption/resume

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

26.826.12353

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11

What issue are you seeing?

[Codex App][Session] Later conversation turns become incorrectly collapsed under an earlier “Continue” turn after interruption/resume

What version of the Codex App are you using?

Latest Codex App version available to my account as of September 3, 2026.

I can provide the exact build number if needed.

What subscription do you have?

Paid ChatGPT subscription.

What platform is your computer?

Windows x64.

What issue are you seeing?

In long-running Codex tasks, conversation history can become incorrectly grouped or collapsed after an interrupted turn is resumed by sending a message such as continue.

The issue usually starts with a long-running task that is interrupted because of a network interruption, temporary model/service failure, or another unexpected interruption.

After the interruption, I send continue to let Codex resume the unfinished task.

Codex successfully continues working, and I may then have several additional rounds of conversation and task execution in the same thread.

At this point, everything appears mostly normal in the active session.

However, after leaving the conversation and later reopening the same Codex thread, multiple later conversation turns appear to have been incorrectly associated with the earlier continue turn.

The later turns are effectively collapsed or hidden underneath that earlier continuation block.

As a result, I can no longer reliably inspect the conversation history after that point.

This is especially problematic for long-running coding tasks because I cannot determine:

• which steps Codex already completed;
• which commands or tools were executed;
• which files were modified;
• which implementation stage the task reached;
• what Codex said in later turns;
• where I should continue the task from.

The important distinction is that this does not look like a simple case of an old conversation being truncated.

The conversation initially contains the later turns and they are visible while the task is active.

The problem becomes apparent after reopening/resuming the conversation, at which point later turns appear to be incorrectly folded into or associated with an earlier continue turn.

In other words, the apparent hierarchy becomes something similar to:

Original task
  |
  +-- normal conversation / execution
  |
  +-- interrupted turn
  |
  +-- User: "continue"
        |
        +-- resumed execution
        +-- later conversation 1
        +-- later conversation 2
        +-- later task
        +-- later task
        +-- ...

After reopening the thread, the UI behaves as though the later conversations belong to that single earlier continuation entry.

Those later turns are then inaccessible or not independently rendered in the normal conversation history.

Steps to reproduce

The issue is intermittent, but I have observed it across multiple long-running Codex conversations.

A typical sequence is:

1. Start a relatively long Codex coding task.

2. Continue working in the same conversation for many turns.

3. During one long-running model/tool execution, allow the task to be unexpectedly interrupted.

   Possible interruption conditions I have encountered include:

   • network interruption;
   • model/service interruption;
   • long-running task stopping unexpectedly.

4. After the interruption, send:

   continue
   

5. Codex resumes the unfinished task.

6. Continue using the same conversation normally.

7. Perform several more rounds of:

   • user instructions;
   • Codex reasoning/execution;
   • tool calls;
   • file modifications;
   • follow-up tasks.

8. Leave or close the conversation.

9. Later, reopen the same Codex conversation.

10. Inspect the conversation around the earlier interruption / continue point.

11. Observe that multiple turns that originally occurred after continue are no longer shown as normal independent conversation turns.

12. The later conversation appears to have been folded, collapsed, hidden, or incorrectly attached beneath the earlier continue execution.

13. It is therefore impossible to determine from the UI where the task actually stopped or what work was completed in the later turns.

Expected behavior

Each user turn and each corresponding Codex task/response should remain independently identifiable in the conversation history.

An interruption followed by continue should resume only the interrupted task.

It should not change the parent/child relationship, grouping, ordering, or visibility of later conversation turns.

After reopening the conversation, Codex should reconstruct the same chronological conversation structure that was visible before the conversation was closed.

For example:

Task A
Codex response

Interrupted task
User: continue
Codex resumed response

Task B
Codex response

Task C
Codex response

Task D
Codex response

The conversation should still have exactly this structure after reopening it.

Actual behavior

After reopening the conversation, the history structure changes.

Several turns after the continue message appear to be incorrectly grouped underneath that continuation turn.

The UI therefore no longer exposes the complete chronological task history.

This makes a long-running development session difficult to safely continue because I cannot determine whether a later implementation step has already been completed.

It can also cause duplicated work because the only practical option is sometimes to ask Codex to perform a step again.

Impact

This is a high-impact issue for long-running Codex workflows.

I use Codex for tasks that can span many conversation turns and multiple implementation stages.

For this workflow, conversation history is not only chat history; it effectively acts as a task execution log.

Once later turns become hidden or incorrectly grouped:

• task progress cannot be verified;
• completed implementation steps cannot be confirmed;
• previous Codex decisions become difficult or impossible to recover;
• it becomes unsafe to assume which changes have already been made;
• users may repeat potentially expensive model/tool operations;
• users may unintentionally modify code twice or overwrite previously completed work.

The longer the task, the more serious the problem becomes.

Additional observations

I have observed this behavior in more than one conversation.

The common pattern appears to be:

long-running thread
→ execution interruption
→ user sends "continue"
→ Codex resumes successfully
→ multiple later turns are created
→ conversation is closed/reopened
→ later turns are incorrectly collapsed/hidden around the earlier continuation boundary

This suggests that the interruption/resume boundary may be relevant to the problem.

Possible areas worth investigating include:

• turn parent/child relationships after continuation;
• persisted turn IDs after an interrupted execution;
• conversation tree reconstruction during thread hydration;
• transcript pagination around interrupted/resumed turns;
• UI grouping of continuation responses;
• ordering of persisted turns after resume;
• whether later turns inherit an incorrect parent turn ID;
• whether a continuation block is incorrectly treated as containing all subsequent turns;
• thread-history projection after an interrupted task is resumed.

I cannot confirm which layer is responsible, so these are only possible investigation areas rather than a root-cause claim.

Data-loss vs. rendering issue

I cannot currently determine whether the later turns are actually missing from persistent storage or whether they are still stored but no longer correctly reconstructed/rendered by the Codex UI.

From the user perspective, however, they are effectively inaccessible.

If there is a supported diagnostic procedure to inspect the underlying thread/rollout data without modifying it, I can provide additional information.

I would prefer not to manually modify Codex's local state or session database because the affected conversations contain important development history.

Related issues

This may be related to existing session/history/resume issues, but the specific behavior I am reporting is the incorrect grouping/collapsing of later turns under an earlier continue turn after an interruption.

Potentially related:

• #42157 — App update/resume duplicates a rollout ordinal and hides later task history
• #31995 — Long conversations show only recent turns although full rollout history remains local
• #37577 — Paginated history can reconstruct completed turns as “interrupted” on resume
• #38792 — Resume opens a long thread at its first turn due to thread-history projection state
• #23399 — /resume conversation view is cut off and cannot scroll full history

I am reporting this separately because the visible symptom and reproduction sequence appear somewhat different:

interruption
→ "continue"
→ successful additional work
→ several later turns
→ reopen thread
→ later turns become associated with / hidden under the earlier continuation

Suggested recovery behavior

Even if Codex detects inconsistent session metadata while reopening a thread, it would be preferable to:

1. preserve all durable turns;
2. reconstruct the transcript from canonical chronological data;
3. avoid hiding subsequent valid turns because of one malformed continuation boundary;
4. display an explicit warning if conversation reconstruction is incomplete;
5. provide a supported repair/reindex mechanism for affected threads.

At minimum, the UI should indicate that the displayed transcript may be incomplete rather than silently presenting an older or incorrectly grouped conversation state.

Willing to provide diagnostics

I can provide sanitized diagnostic information if the maintainers specify what is useful, for example:

• Codex App version;
• affected thread ID;
• timestamps around the interruption;
• screenshots before/after reopening;
• application logs;
• sanitized session metadata;
• rollout metadata;
• whether the underlying later turns are still present locally.

I would prefer to provide raw thread contents or identifiers through a non-public channel because the affected conversations contain project source-code information.

What steps can reproduce the bug?

This is a Codex App conversation/session reconstruction issue and does not require a code snippet to reproduce.

Reproduction steps

1. Start a relatively long-running task in a Codex conversation.

2. Continue working in the same conversation for multiple turns.

3. During one long-running Codex execution, let the execution be interrupted unexpectedly.

   I have encountered interruptions caused by:

   • a network interruption;
   • a temporary model/service interruption;
   • a long-running execution stopping unexpectedly.

4. After the interruption, send:

   continue

5. Codex successfully resumes the interrupted task.

6. Continue using the same conversation normally and create several additional independent turns/tasks after the resumed execution.

   For example:

   Task A
   → Codex execution
   → execution interrupted
   → User: continue
   → Codex resumes successfully
   → Task B
   → Response B
   → Task C
   → Response C
   → Task D
   → Response D

7. While the conversation remains open, the later turns are visible normally.

8. Leave/close the conversation.

9. Later, reopen the same Codex conversation from the conversation/task history.

10. Scroll to the earlier interruption / continue location.

11. Observe that multiple later conversation turns are no longer displayed as independent chronological turns.

12. Instead, the later turns appear to have been incorrectly associated with, grouped under, or collapsed into the earlier continue turn.

13. As a result, the later task history becomes inaccessible or cannot be reliably inspected from the UI.

This has occurred in multiple long-running conversations, although I do not yet have a guaranteed minimal reproduction case.

The common pattern I have observed is:

long-running conversation
→ execution interrupted
→ send continue
→ Codex resumes successfully
→ several additional turns/tasks
→ close conversation
→ reopen conversation
→ later turns become hidden/collapsed around the earlier continue boundary

No code snippet is required to reproduce this issue because it appears to be related to Codex App session persistence / conversation reconstruction rather than the contents of the coding task.

Session ID: [I can provide the affected session/thread ID if maintainers specify where to obtain it safely.]

What is the expected behavior?

The complete chronological conversation history should remain unchanged after closing and reopening the Codex conversation.

An interrupted execution followed by continue should only resume that interrupted execution.

It should not change the parent/child relationship, ordering, grouping, visibility, or persistence of any subsequent conversation turns.

For example, if the original conversation is:

Task A
→ interrupted execution
→ User: continue
→ resumed response
→ Task B
→ Response B
→ Task C
→ Response C
→ Task D
→ Response D

then after reopening the conversation, the UI should reconstruct and display exactly the same sequence.

All later turns should remain independently visible and accessible.

If Codex detects inconsistent or incomplete session metadata while restoring a conversation, it should preserve all valid persisted turns and display a warning rather than silently hiding or collapsing later conversation history.

Additional information

No response

Start with the conversation/task history reopening path and inspect thread hydration, transcript pagination, and persisted turn IDs around an interrupted turn followed by continue. Reproduce the sequence with later independent turns, then verify that reopening preserves their chronological order and visibility rather than grouping them under the continuation.