›_ Codex Issues
Codex Issues / #40515

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

Open 💬 5 comments Opened Aug 25, 2026 by charleywang-sh
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

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

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #40452
  • #40342
  • #40512

Powered by Codex Action

321Fontsize · 3 days ago

same here

yangyixuan0704 · 1 day ago

I can independently reproduce this on macOS + Codex Desktop Remote SSH.

My affected remote rollout is intact (5.5 MB, 1239 JSONL records) and contains the later completed work, final assistant response, and an explicit final task_complete. However both Desktop and codex resume <exact-session-id> reconstruct only the beginning of the conversation and mark it interrupted.

Keyword checks on the raw rollout include Phase 2B2 ×15, final commit prefix d478481 ×7, and task_complete ×3.

Clearing Desktop renderer caches and Session Storage did not help. This strongly appears to be history reconstruction/app-server state rather than lost rollout data.

Happy to provide additional sanitized diagnostics if useful; I cannot share the full rollout because it contains private project content.

detydanesu · 22 hours ago

I can reproduce this issue on Windows Desktop with a built-in SSH Remote connection to an OpenWrt ARM64 host.

Environment:

  • Codex Desktop for Windows: 26.820.9563.0
  • Remote OS: OpenWrt, ARM64
  • Remote Codex CLI: 0.150.1
  • The persistent remote app-server was initially still running 0.146.0 after the CLI update. I restarted the OpenWrt service and verified that the CLI, app-server, and code-mode-host were all using the 0.150.1 release. The history truncation still persists.

Concrete evidence from one affected thread:

  • The remote rollout-*.jsonl contains 332 records.
  • The terminal record at ordinal 331 is an event_msg with payload.type = "task_complete" and a complete last_agent_message.
  • Desktop's thread view/API returns only one turn with status = "interrupted", completedAt = null, and four visible items: the user prompt, an initial reasoning summary, the first commentary message, and the first completed command.
  • The Desktop response reports hasMore = false, even though hundreds of later rollout records exist.
  • Reopening the remote project and restarting Desktop does not rehydrate the missing events.
  • The remote service is healthy and the root filesystem is only 52% used.

This rules out missing model output, disk exhaustion, and merely having a stale remote daemon version. It looks like paginated history projection/hydration stops at an earlier interrupted boundary and does not reconcile against the terminal rollout events.

I am not attaching the raw rollout because it contains private prompts, paths, and tool output, but I can provide a sanitized event timeline if useful.

gautamg795 · 3 hours ago

Additional reproduction data from another user:

  • Remote host: Linux, accessed from Codex Desktop on Windows.
  • The same affected threads are truncated when opened through Codex on iOS, so the symptom is not limited to one desktop client.
  • The remote UI shows only the initial prompt/commentary (and sometimes the first command), while the corresponding local rollout-*.jsonl files contain the completed work, including final assistant responses and task_complete.
  • Two confirmed affected rollouts are only approximately 1.27 MB and 3.41 MB, and neither contains a compaction event. This makes rollout size/compaction an unlikely trigger in these cases.
  • The original remote app-server process had been long-lived. It was fully stopped and replaced (not merely reconnected), and the remote Codex CLI/app-server was upgraded from 0.146.0 to 0.150.1.
  • After the fresh app-server and proxy started, the already-affected threads remained truncated on both Windows and iOS.
  • The app-server control socket is owned by the new process and new tasks can run, so the restart itself appears healthy; it simply does not reconcile the persisted rollout with the stale thread/index view.

This further suggests persisted thread-state/index hydration is failing independently of the complete rollout, and that a normal app-server restart does not rebuild or reconcile it.

No private rollout contents are attached, but sanitized event timelines or thread IDs can be provided if useful.

_This comment was created and posted by OpenAI Codex at the user's request._