[Windows App] Agent-initiated reboot leaves orphaned turn, truncates later messages, and shows stale Stop button

What version of the Codex App are you using?

• Codex Windows app: 26.825.4187.0
• Codex CLI/app-server: 0.139.0

What platform is your computer?

Windows 11 x64, build 10.0.26200.9168.

What issue are you seeing?

When Codex itself executes an immediate Windows reboot from inside an active local turn, the host shuts down before the turn can emit its terminal event. After Windows and Codex restart, the task UI rehydrates from that orphaned turn instead of reconciling the later durable transcript.

Observed UI state after reopening the task:

• The visible timeline is truncated at the successful shutdown.exe /r /t 0 tool call.
• The composer initially shows the Stop/Pause button as if the turn were still running.
• Typing any text changes the control to the normal Send arrow.
• Pressing Stop/Pause does not restore the missing messages. It only changes the displayed message cutoff/update time to the current time.
• Sending a new message can continue the task, but later messages already present in the local rollout remain absent from the UI/thread reconstruction.

The transcript data is not lost. The local rollout JSONL contains the missing assistant messages, tool calls, subsequent user turns, and later normally completed turns. The task list also has a much newer updatedAt than the last turn reconstructed by the UI.

This reproduced twice around Codex-driven Windows reboot validation.

What steps can reproduce the bug?

1. Start a local Windows task in Codex Desktop.
2. Keep the current assistant turn active.
3. Approve a tool call that executes:

   shutdown.exe /r /t 0
   

4. Let Windows reboot and relaunch Codex.
5. Open the same task.
6. Observe that the timeline stops at the reboot command and the composer displays a stale Stop/Pause button.
7. Type in the composer; the button changes to Send.
8. Press Stop/Pause before typing, or send a continuation message.
9. Observe that Stop only advances the cutoff/update timestamp and does not rehydrate later persisted transcript events.

Diagnostic evidence

For one captured occurrence, the rollout contains this sequence:

• task_started
• normal assistant messages and completed tool calls
• successful CommandExecution for shutdown.exe /r /t 0
• host reboot before a matching task_complete could be persisted
• after restart, a new user continuation and many later assistant/tool events were appended to the same rollout
• later turns include valid terminal events

However, the reopened task reader continues to expose the pre-reboot turn as:

• status: interrupted
• completedAt: null
• latest visible content ending at the reboot command

It omits the later authoritative rollout ordinals even though the task-level updatedAt reflects them.

No prompt contents, task UUIDs, usernames, local paths, repository names, commit hashes, credentials, or private source information are included in this report.

Expected behavior

Codex should safely handle an approved agent-initiated host reboot.

At minimum, after restart the app should:

1. Detect that the pre-reboot process died while the turn was active and mark that turn interrupted without leaving a stale running control.
2. Reconcile all later authoritative events in the durable rollout instead of allowing the orphaned turn/index entry to truncate the timeline.
3. Make Stop/Pause either terminate a real active turn or clearly report that no backend turn is attached.
4. Preserve Send/Stop state consistently with the actual backend turn.
5. Consider guarding immediate host-shutdown commands, or schedule them only after the current turn has durably emitted its terminal state.

Related issue

Related to #39885, but the captured terminal condition differs:

• #39885 has a persisted final assistant response and task_complete, yet rehydrates as interrupted.
• This report is triggered by Codex terminating its own Windows host mid-turn, leaving no matching task_complete; later valid rollout events still exist but are hidden behind the orphaned turn.

Both cases may share stale-state precedence during thread reconstruction.

Start by reproducing the reboot sequence and tracing the task reader, turn/index reconstruction, and Stop/Pause state described in the report; no specific files or tests are named. Verify that an interrupted pre-reboot turn cannot hide later authoritative rollout events, and that the controls reflect whether a backend turn is actually attached.