Remote SSH threads show only the initial response while completed turns remain in rollout JSONL

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.21641 (build 6849)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Summary

Several recent Codex Desktop threads connected to an SSH remote project display only the user prompt and the first short assistant commentary message. The Desktop thread index reports the turn as interrupted, with no visible final answer.

However, the remote rollout-*.jsonl files contain later tool calls, assistant messages, final_answer, token_count, and task_complete. The underlying tasks completed, but Desktop did not hydrate or index the later events.

This appears to be a Desktop / SSH app-server lifecycle or thread-state synchronization issue rather than missing model output.

Observed evidence

• Reproduced across multiple unrelated SSH remote threads.
• Desktop/list API reports interrupted and no completedAt.
• Desktop shows only the initial commentary and sometimes the first command.
• The first command completed successfully with exit code 0.
• Corresponding rollout JSONL files continued growing to approximately 7–20 MB.
• Some affected files contain an assistant final_answer followed by task_complete.
• The SSH proxy/app-server had remained alive across multiple Desktop sessions.
• Local bundled CLI/app-server and the remote CLI were on different nearby versions.

The persisted transcript and Desktop thread index therefore disagree about turn status and contents.

What steps can reproduce the bug?

1. Use Codex Desktop on macOS and connect to a Linux project through the built-in SSH connection.
2. Start several normal tasks that read project files and execute shell commands.
3. Allow each task to continue running.
4. Reopen the affected threads in Desktop.
5. Observe that the UI shows only the prompt, initial assistant commentary, and sometimes the first command; the turn is marked interrupted.
6. On the remote host, inspect ~/.codex/sessions/.../rollout-*.jsonl.
7. Observe that the same rollout contains subsequent tool activity and, in some cases, final_answer and task_complete.

The issue has occurred repeatedly but I do not yet have a deterministic single-thread trigger. Full rollout files are not attached because they contain private prompts, project paths, and tool output.

What is the expected behavior?

When the remote rollout contains a completed turn, reconnecting or reopening the thread should hydrate all persisted messages, show the final assistant response, and report the turn as completed.

If hydration fails, Desktop should show a recoverable synchronization error rather than silently presenting the transcript as interrupted at the first command.

Additional information

Environment:

• Local platform: Darwin 25.5.0 arm64 arm
• Codex/ChatGPT Desktop: 26.818.21641, build 6849
• Bundled local Codex CLI: 0.148.0-alpha.21
• Remote OS: Linux over built-in SSH
• Remote Codex CLI: 0.149.0

Possible areas:

• stale SSH app-server/proxy ownership;
• dropped lifecycle events;
• resume/hydration stopping at an earlier interrupted ordinal;
• local/remote app-server protocol version skew;
• thread index not reconciled with terminal rollout events.

Related reports:

• https://github.com/openai/codex/issues/38341
• https://github.com/openai/codex/issues/24287
• https://github.com/openai/codex/issues/19608
• https://github.com/openai/codex/issues/24467
• https://github.com/openai/codex/issues/37969

I can provide sanitized event timelines and affected thread IDs privately.

Compare the Desktop/list API's interrupted status with remote ~/.codex/sessions/.../rollout-*.jsonl events, especially final_answer, token_count, and task_complete. Trace the SSH proxy/app-server lifecycle and resume or hydration path, including the local 0.148.0-alpha.21 and remote 0.149.0 versions, and review the related issues listed. Done means a reopened completed remote turn hydrates all persisted messages and reports completed, or shows a recoverable synchronization error.