[Windows][Mobile Remote Control] Sending a message can create an unmaterialized ghost thread that cannot be resumed or archived

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

• #38965
• #38724

Powered by Codex Action

Hi @WangLufei233, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.

If you still have the affected local Codex directory, you can inspect it via:

pip install codex-rescue==0.1.0a5
codex-rescue sessions --json

No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.

if I pair both devices using method in this thread, it seems like I can use it without creating a ghost thread anymore.

Second partial-creation shape: state row and shell snapshot committed, but rollout never materialized

I observed a related ghost task from Windows Desktop against an SSH-backed Linux app-server. This variant is useful because it captures a different transaction boundary from the original report.

Environment

• Windows 11 ARM64
• Codex Desktop: 26.825.4187.0
• Desktop-bundled runtime: codex-cli 0.150.0-alpha.12.2
• Remote Linux app-server: codex-cli 0.150.1
• The thread/start log identified the Desktop client as 26.825.32147
• Task source recorded as vscode
• Requested history mode: paginated

Immediate post-failure evidence

The UI created/opened a task placeholder, but no message could be submitted. Read-only inspection immediately after the failure found:

• one threads state row for the generated task ID;
• a non-empty rollout_path stored in that row;
• has_user_event = 0;
• tokens_used = 0;
• no model or reasoning value;
• no first-user-message or preview text;
• the referenced rollout file did not exist;
• no matching rollout existed anywhere in active or archived session storage;
• thread_turns = 0;
• thread_items = 0;
• thread_realtime_items = 0;
• thread_history_projection_state = 0.

The app-server log contains the beginning of thread/start, including successful configuration resolution and successful creation of a shell snapshot. It contains no later completion, error, or usable thread response for that request.

The shell snapshot was approximately 630 KB. Therefore, creation progressed far enough to persist both task metadata and an auxiliary artifact, but stopped before writing the rollout's initial session_meta.

The first native read reported an invalid paginated lineage with a missing source rollout. A later read-only check, after runtime cleanup, found that the state row and shell snapshot had been removed and the task became completely unresolvable. No persisted user content was present at any stage.

Why this differs from the original report

The original report found a visible placeholder with no matching thread-state row. In this reproduction, the state row and shell snapshot were briefly committed, while the canonical rollout was absent. Both shapes point to non-atomic task creation, but this one narrows the failure window to after metadata/snapshot persistence and before rollout materialization or successful thread/start completion.

Expected behavior

thread/start should be atomic from the client perspective:

1. create the initial rollout with session_meta;
2. commit history/state metadata that references it;
3. return/expose the task only after those writes succeed.

If any step fails or the client disconnects, Codex should roll back the provisional row and artifacts before exposing the task. The client should receive a terminal creation error and retain the unsent composer text.

Actual behavior

Desktop can expose a task whose state row points to a nonexistent rollout. The task cannot accept input, read operations fail with lineage/missing-rollout errors, and later cleanup can make the same task ID disappear entirely.

A regression test should inject cancellation between shell-snapshot creation and rollout creation, then assert that no externally visible task, catalog entry, state row, snapshot, or client binding survives unless the rollout has been materialized.