[Windows App] Completed response disappears after restart; turn rehydrates as interrupted

What version of the Codex App are you using?

The Windows app version was not available from the remote-host transcript. The affected session records:

• Originator: Codex Desktop
• Codex CLI/app-server version: 0.146.0
• Execution target: Remote SSH host

What platform is your computer?

Codex Windows desktop app connected to a Linux Remote SSH host.

What issue are you seeing?

A completed assistant response was visible in the task. While composing a reply, I closed Codex. After reopening the Windows app, the task displayed only the original user prompt; the completed assistant response had disappeared.

The response was not lost from the underlying transcript. Read-only inspection found the full assistant final answer followed by a normal task_complete event. However, the reopened app/thread API reconstructed the same turn as interrupted and stopped before the final answer.

Affected task/session ID:

01a0231b-f2b1-7be2-bf83-97cca607da58

The task used subagents before producing the parent final answer. This may be relevant, but the missing content was the parent task's final response, not a child status card.

What steps can reproduce the bug?

1. In the Windows Codex app, start a task on a Remote SSH project.
2. Let the task spawn subagents and finish normally.
3. Confirm the parent task's final assistant response is visible.
4. Begin composing a reply.
5. Close Codex, then reopen it.
6. Open the same task.
7. Observe that only the original user prompt is displayed and the assistant final response is absent.

This report is based on one captured occurrence; the shutdown/reopen behavior has not yet been loop-tested.

Diagnostic evidence

The raw JSONL transcript on the remote host contains:

• Parent assistant final response at 2026-08-21T07:02:26.781Z
• task_complete at 2026-08-21T07:02:27.232Z

The reopened task reader instead reported:

• Turn status: interrupted
• Visible reconstruction ending around 2026-08-21T06:57:34Z
• completedAt: null
• No final assistant response

The local session index entry was also stale:

• updated_at: 2026-08-21T06:57:21.614Z

The task list separately carried a later updated timestamp corresponding to completion, so persisted task sources disagreed about the same turn.

As a recovery test, the final answer was extracted from the raw transcript and sent back to the same task. The new turn completed and became visible normally. This confirms the original response data existed and points to thread indexing/rehydration rather than model generation or transcript loss.

No prompt contents, project names, filesystem paths, credentials, or private repository information are included here.

What is the expected behavior?

A parent turn with a persisted final assistant message and task_complete must rehydrate as completed after app restart. The UI/thread reader should not let an earlier interrupted or stale indexed state override later authoritative transcript events.

Thread reconstruction should reconcile the newest terminal event across the raw transcript, task index, watch state, and Remote SSH metadata.

Potentially related

#37916 describes stale watched status overriding completed subagent state during enrichment. This report may involve the same class of stale-state precedence, but it is distinct: the parent final assistant response disappears from the reconstructed conversation after restart.

Start at the reopened task reader and thread API, then compare their reconstruction with the raw JSONL transcript, task index, and watch state described in the report. Trace why the stale interrupted status wins over the later task_complete event; done means the parent final response rehydrates as completed after restarting the Windows app.