[Windows Desktop GUI] Active plan card and step progress are lost after interrupt and continue

Product surface

Codex Desktop GUI for Windows. This is not a Codex CLI or terminal TUI issue.

Suggested labels: bug, app, session, plan.

Version and platform

• Microsoft Store/MSIX package: 26.727.6591.0
• Internal Codex app release: 26.727.51351
• Chromium: 150.0.7871.182
• Windows: 10.0.26200, x64

What issue are you seeing?

During a multi-step task, Codex Desktop displays an active plan card containing the planned steps and a progress pill such as Step 1 / 5.

If the user manually interrupts the running turn and then sends continue in the same task, Codex can continue doing the work, but the active plan card and step-progress pill are no longer restored. Progress/commentary produced by the continued turn also appears as a separate sequence and cannot be merged or collapsed back into the original plan/work group.

On long tasks this leaves a large volume of program-execution narration, tool activity, and progress text permanently expanded in the transcript instead of being contained in the normal collapsible work/plan presentation. The result is a long wall of process text that is difficult to navigate.

This breaks the visual continuity of one logical task: the transcript remains in the same task and the agent continues the same objective, but the UI no longer shows which plan step is active or groups the resumed activity under the existing plan.

Control comparison: before interruption, the same task shows the plan card, step counter, and collapsible process presentation normally. The presentation changes only after the interruption followed by continue.

Steps to reproduce

1. Start a multi-step task in Codex Desktop that produces an active plan card.
2. Confirm that the card lists multiple steps and shows a progress pill such as Step 1 / 5.
3. Manually interrupt/stop the turn before the plan is complete.
4. In the same task, send continue.
5. Observe that work resumes, but the active plan card and its step counter do not return.
6. Observe that new progress/commentary and program-execution text are not grouped or collapsible with the original plan activity and remain expanded in the transcript.

Expected behavior

• An incomplete plan should remain durable at the task/thread level after a manual interruption.
• Sending continue in the same task should rehydrate the existing plan, preserve completed/current/pending step status, and continue the step counter from its previous value.
• New progress/commentary, tool activity, and program-execution narration should attach to the same logical plan group and use the same collapsible presentation.
• If an interrupted plan cannot be resumed, the app should explicitly mark it as interrupted/abandoned and offer a clear resume path instead of silently dropping the plan UI.

Actual behavior

• The continued work appears to be presented as a separate ordinary turn.
• The active plan card and Step N / M progress pill disappear.
• The user can no longer see which original plan step is active.
• Continued progress/commentary and program-execution text cannot be merged or collapsed with the original plan sequence.
• Large amounts of process text remain expanded, making long resumed tasks difficult to read and navigate.

Root-cause boundary

The observed defect is in Desktop plan/progress presentation and continuity. This report does not claim that the model necessarily forgot the objective or that backend task context was lost. A plausible hypothesis is that the plan and collapsible activity-group ownership remain scoped to the interrupted execution turn, while continue creates a new turn without rehydrating the prior plan/group identity. The available evidence does not prove that hypothesis or distinguish it from renderer or app-server session-state loss.

Related issues, but not exact duplicates

• #3365 reports loss of intermediate steps after interrupt and continue in the VS extension. It does not cover the Desktop plan card, step counter, or resumed grouping behavior.
• #26257 requests a true Resume button after manually stopping a Desktop task, but does not report plan-card or folding loss.
• #32924 requests stable activity sequence numbers across resume/reconnect, but does not cover an existing plan card disappearing.
• #34418 reports incorrect Desktop collapsing across a Stop-hook continuation, but uses a different trigger and presentation failure.

Additional information

A local screenshot confirms the affected UI component: a five-item plan card with a Step 1 / 5 progress pill. It is not attached publicly because it contains local conversation text.

Disclosure: this issue and its local diagnostic summary were prepared and submitted by Codex at the account owner's request. The account owner did not manually write or post the report.