[Desktop/remote SSH] Completed codex exec thread is readable but task link fails with "no rollout found"

What version of the Codex App are you using?

• Remote Codex CLI: 0.153.2
• Remote app-server: 0.153.2 (running, ephemeral mode)
• Desktop build number: not exposed by the remote diagnostics available to the agent
• Reproduced: 2026-09-04 UTC

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Codex Desktop connected to a remote SSH workspace.

Remote Codex host:

• Ubuntu 24.04.4 LTS
• Linux 6.8.0-138-generic
• x86_64
• Codex installed through npm
• ChatGPT authentication / OpenAI provider
• No proxy configured
• HTTP provider reachability and Responses WebSocket handshake both pass

The local Desktop OS/build is not visible from the remote diagnostic surface.

What issue are you seeing?

A completed, persisted, paginated thread created by codex exec on the same connected remote host can be read through the Codex App thread API and renamed successfully, but it is omitted from the Desktop thread list. Opening it through an in-app created-thread link fails with:

恢复对话失败
no rollout found for thread id 01a06ab5-779a-7653-99a3-0b28e61f1fd3

This is inconsistent with the underlying state: the exact rollout file exists, the state DB row exists, and the turn is readable and completed.

What steps can reproduce the bug?

1. Open a Codex Desktop task backed by a remote SSH project.
2. From that task, attempt to create a new user-visible Codex task. In this reproduction, the native create_thread capability was not exposed, so the same remote Codex installation was used:

   codex exec -C <repo> -s read-only --json "测试ultra"
   

3. Codex returns:

   {"type":"thread.started","thread_id":"01a06ab5-779a-7653-99a3-0b28e61f1fd3"}
   {"type":"turn.started"}
   {"type":"item.completed","item":{"type":"agent_message","text":"收到，Ultra 模式测试正常。可以直接给我任务。"}}
   {"type":"turn.completed"}
   

4. Query the thread through the Codex App thread-read capability. It returns the full completed turn. Renaming it to 测试ultra also succeeds.
5. Query the Desktop thread list with a limit of 50. The target thread is absent; there are no unavailable hosts or sources.
6. Open the emitted created-thread link for that thread.
7. Desktop shows no rollout found for thread id ....

Local diagnostic evidence

Target thread:

• Thread ID: 01a06ab5-779a-7653-99a3-0b28e61f1fd3
• Rollout exists at a normal active-session path under ~/.codex/sessions/2026/09/04/
• Rollout size after completion: 129,398 bytes
• State DB row exists
• source=exec
• thread_source=user
• history_mode=paginated
• archived=0
• cli_version=0.153.2

The supported read-only migration check reports:

{
  "thread_id": "01a06ab5-779a-7653-99a3-0b28e61f1fd3",
  "status": "already_paginated",
  "bytes_processed": 0,
  "message": null
}

The app-side read result reports the thread as status.type="notLoaded", while still returning its completed turn and timestamps.

codex doctor --json also reports healthy state/history DB integrity but a broader inventory warning:

• 426 active rollout files vs 419 active state rows
• 7 active rollout files missing rows
• 6 duplicate rollout thread IDs
• 0 scan errors and 0 malformed filenames

The target thread itself does have a state DB row, so this broader parity warning may be correlated but does not directly explain the false “no rollout found” result. Doctor explicitly recommends attaching the report for this class of inventory mismatch.

What is the expected behavior?

If a non-ephemeral user thread:

• has a completed turn,
• has an existing rollout file,
• has a state DB row,
• is already paginated, and
• can be resolved by the app-side read API,

then Desktop should be able to open it from a task link and should not report that no rollout exists.

If CLI-created threads are intentionally unsupported in Desktop, the app should reject the link deterministically with an accurate compatibility message instead of a false missing-rollout error.

Actual behavior

• App-side read succeeds.
• App-side rename succeeds.
• Desktop list omits the thread.
• Opening the task link fails with no rollout found.

Additional information

No raw rollout, database, private repository path, remote host address, account identifier, auth material, or private logs are attached. A screenshot of the exact error and a redacted full codex doctor --json report are available if maintainers need them.

Potentially related, but not identical:

• #36516 and #33046: same Desktop error surface
• #31158: naming before the first turn; this reproduction differs because the turn completed and the rollout exists before opening
• #42099: zero-turn persistence regression; this reproduction has a completed turn
• #41814 and #31433: rollout/state inventory drift

Start with the codex doctor --json inventory report and compare the target thread's state DB row, rollout file, and app-side read result. Trace how the Desktop thread list and created-thread link resolve this completed source=exec thread. Done means the valid thread opens and appears in the list, or unsupported CLI-created threads receive an accurate compatibility error.