I am seeing a recurring Codex Desktop issue with SSH remote projects.
Several recent remote threads show only:
my original prompt; and
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.
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.
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.
I asked ChatGPT to look for the closest related issue, and it identified:
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 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
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.
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.
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.
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.