Repository navigation
[Windows App] Completed response disappears after restart; turn rehydrates as interrupted #39885
Description
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?
- In the Windows Codex app, start a task on a Remote SSH project.
- Let the task spawn subagents and finish normally.
- Confirm the parent task's final assistant response is visible.
- Begin composing a reply.
- Close Codex, then reopen it.
- Open the same task.
- 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_completeat2026-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.
Activity
github-actions commentedon Aug 21, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
SpaceMatthieu commentedon Aug 24, 2026
I am seeing the same behavior repeatedly with Codex Desktop on Windows connected to a Linux host through Remote SSH. When reopening an existing conversation, the thread sometimes renders an older state: I may see only an earlier user prompt, while one or several subsequent assistant responses/user turns are missing from the UI.
Importantly, the missing context does not appear to be lost. If I send a new prompt such as “Could you repeat your last response?”, Codex is able to reproduce the missing response, and the conversation then continues normally. This suggests that the remote session/context is intact but Desktop is hydrating/rendering a stale or truncated version of the transcript.
nos1609 commentedon Aug 26, 2026
Additional sanitized reproduction on a newer runtime.
Environment:
0.149.0-alpha.4.10.149.1Observed state:
interrupted;completedAtis null;This extends the original report beyond the earlier 0.146.0 occurrence: a completed final can remain present in the persisted transcript while the reconstructed lifecycle state contradicts it.
Project names, prompts, local paths, hostnames, account data, and task IDs are omitted.
Prevent restored Desktop tasks from replaying completed history
euujann commentedon Sep 8, 2026
I can reproduce the same issue on Windows Codex Desktop using a Linux host over Remote SSH.
The affected task actually completed successfully on the remote host. Read-only inspection of the remote rollout JSONL shows both the final assistant response and a normal task_complete event for the affected turn.
After rebooting Windows and reopening Codex Desktop, however, the UI restores the task at an earlier intermediate execution step and presents it as if the completed turn were still unfinished/paused.
I reproduced this again after updating both Codex Desktop and the Codex CLI on the remote Linux host.
Environment:
Client: Codex Desktop on Windows
Execution target: Linux over Remote SSH
Remote session storage: ~/.codex/sessions/.../rollout-*.jsonl
Evidence from the affected rollout:
Thread ID: 01a06f6e-7d22-7cc3-95a2-503eb8b47f27
Affected turn ID: 01a08035-ece7-7d91-b939-e5488e3559d9
final_answer: present
task_complete: present
Actual code work and validation had completed
After Windows reboot, Desktop restored an earlier intermediate state instead of the completed turn
This appears to be a thread/session rehydration or history projection problem rather than an execution failure, because the durable remote rollout contains the completed turn.
I can provide the relevant rollout excerpts, Desktop version, remote CLI version, and screenshots if useful.
WBWIT commentedon Sep 21, 2026
Still relevant as of September 21, 2026: I observed a completed assistant response disappear in Codex Desktop on Windows with installed Store package:
OpenAI.Codex_26.915.4065.0_x64__2p2nqsd0c76g0This occurrence was in a local projectless task, with a different trigger from the original report:
request_user_input_asyncand continued working on another part of my request.The missing answer remained available in the conversation context supplied to the assistant. No app restart or Remote SSH connection was involved in this occurrence. This supports a similar visible-history symptom, but I have not verified that it shares the same underlying cause as the restart/rehydration issue reported here, nor inspected persisted lifecycle events for this occurrence.
Expected: answering a pending asynchronous question should preserve every already-completed assistant response in the visible conversation.