# Codex Desktop Remote SSH threads show only the initial response although rollout JSONL contains the completed turn **URL:** \ **Category:** Codex\ **Tags:** bug, macos, codex-app\ **Created:** [August 25, 2026, 2:09am UTC](https://community.openai.com/t/codex-desktop-remote-ssh-threads-show-only-the-initial-response-although-rollout-jsonl-contains-the-completed-turn/1392366 "2026-08-25T02:09:57Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![charley450](https://avatars.discourse-cdn.com/v4/letter/c/e56c9b/32.png) [@charley450](https://community.openai.com/u/charley450)\ **Post date:** [August 25, 2026, 2:09am UTC](https://community.openai.com/t/codex-desktop-remote-ssh-threads-show-only-the-initial-response-although-rollout-jsonl-contains-the-completed-turn/1392366/1 "2026-08-25T02:09:57Z")
I am seeing a recurring Codex Desktop issue with SSH remote projects. Several recent remote threads show only: 1. my original prompt; and 2. the first short assistant commentary message, sometimes followed by the first command. The Desktop thread index reports the turn as **interrupted** , with no visible final answer. However, inspection of the remote host shows that the corresponding `~/.codex/sessions/.../rollout-*.jsonl` files continued growing and contain later tool calls. Some contain `final_answer` and `task_complete`. This means the work and transcript were persisted on the remote server, but the Desktop UI/index stopped hydrating events near the first command. **Environment** - macOS, arm64 - Codex/ChatGPT Desktop 26.818.21641, build 6849 - Bundled local Codex CLI 0.148.0-alpha.21 - Linux remote host through the built-in SSH connection - Remote Codex CLI 0.149.0 - Affected rollout files were approximately 7–20 MB - The SSH app-server proxy had remained alive across multiple Desktop sessions This looks like an SSH app-server lifecycle or thread-state synchronization problem rather than lost model output. A stale proxy, a dropped completion event, resume/hydration stopping at an earlier interrupted ordinal, or nearby local/remote protocol version skew may be involved. Similar reports: - [History returns to an earlier interruption while later work remains logged](https://github.com/openai/codex/issues/38341) - [Backend work continues while Desktop UI becomes detached](https://github.com/openai/codex/issues/24287) - [Remote-SSH hydration fails while session files still exist](https://github.com/openai/codex/issues/19608) - [Desktop completed/interrupted state disagrees with streaming state](https://github.com/openai/codex/issues/24467) - [Stale SSH-owned app-server affects thread access](https://github.com/openai/codex/issues/37969) Has anyone seen this exact variant where only the opening assistant message remains visible although `final_answer` and `task_complete` exist in the remote rollout? I have deliberately omitted thread IDs, server names, project paths, prompts, and full logs. I can provide sanitized event timelines privately if maintainers need them. ---
**Author:** ![EricGT](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/ericgt/32/20571_2.png) [@EricGT](https://community.openai.com/u/EricGT)\ **Post date:** [August 25, 2026, 8:55am UTC](https://community.openai.com/t/codex-desktop-remote-ssh-threads-show-only-the-initial-response-although-rollout-jsonl-contains-the-completed-turn/1392366/2 "2026-08-25T08:55:46Z")
Welcome to the forum! Nice job on locating other Codex issues as listed in **Similar reports** Note for others: You are welcome to discuss Codex issues here. However, the official place to report and track them is the [OpenAI Codex GitHub issue tracker](https://github.com/openai/codex/issues). I asked ChatGPT to look for the closest related issue, and it identified: > > > \### What version of the Codex App are you using? > > The Windows app version was no…t 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. If that issue matches your problem, consider adding a 👍 reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users. If it does not describe the same problem, and since your search of the [existing Codex issues](https://github.com/openai/codex/issues) did not find a closer match, if you cannot find one, open a new issue and include as much relevant detail as possible. * * * The model and prompt used to find that issue Model: ChatGPT 5.5 Medium > **Prompt** > > ```plaintext > fetch: https://community.openai.com/t/codex-desktop-remote-ssh-threads-show-only-the-initial-response-although-rollout-jsonl-contains-the-completed-turn/1392366 > > For the noted forum post can you check what is the closest related issue at > > https://github.com/openai/codex/issues > > and list why? > > If the issue is closed also search for the closest open issue. > > Include a link to the GitHub issue and the number if you note a specific one. > > ``` ---
**Author:** ![go2play](https://avatars.discourse-cdn.com/v4/letter/g/58956e/32.png) [@go2play](https://community.openai.com/u/go2play)\ **Post date:** [August 29, 2026, 9:33am UTC](https://community.openai.com/t/codex-desktop-remote-ssh-threads-show-only-the-initial-response-although-rollout-jsonl-contains-the-completed-turn/1392366/3 "2026-08-29T09:33:19Z")
I have a hypothesis about what may be causing this. It looks like some older turns in the remote session can remain incorrectly marked as `inProgress`, with `completedAt: null`, even though later turns have already completed successfully. If the client reconstructs the conversation by replaying turns in order and treats the first `inProgress` / incomplete turn as the current active turn, it may stop hydrating the transcript at that point. This would explain why: - the UI consistently misses the last several turns; - the remote session itself is still alive; - new prompts can still be sent and processed normally; - the missing later turns are still present in the underlying session/event log. In other words, this may be less of a connectivity issue and more of a stale turn-state / conversation materialization issue. A useful invariant might be: an `inProgress` turn should not have later successor turns that are already completed. If such a state exists, the client could perhaps ignore or repair the stale `inProgress` marker during hydration. ---
**Author:** ![OpenAI\_Support](https://sea2.discourse-cdn.com/openai1/user_avatar/community.openai.com/openai_support/32/561845_2.png) [@OpenAI\_Support](https://community.openai.com/u/OpenAI_Support)\ **Post date:** [October 14, 2026, 2:53pm UTC](https://community.openai.com/t/codex-desktop-remote-ssh-threads-show-only-the-initial-response-although-rollout-jsonl-contains-the-completed-turn/1392366/4 "2026-10-14T14:53:00Z")
Hey @charley450, thanks for flagging this and sharing the detailed checks. Are you still seeing only the initial response in your Remote SSH conversations? If so, please share your current Desktop app version and the Codex CLI version on the remote host. ~ Ziad ---
**Author:** ![charley450](https://avatars.discourse-cdn.com/v4/letter/c/e56c9b/32.png) [@charley450](https://community.openai.com/u/charley450)\ **Post date:** [October 15, 2026, 9:02am UTC](https://community.openai.com/t/codex-desktop-remote-ssh-threads-show-only-the-initial-response-although-rollout-jsonl-contains-the-completed-turn/1392366/5 "2026-10-15T09:02:44Z")
Thanks for following up. The issue is no longer occurring on my side. Thank you for your help.