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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   remote

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Aug 18, 2026
2. github-actions commented on Aug 18, 2026

   

   github-actionsbot

   on Aug 18, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [app][macOS][26.810.41047] Realtime voice leaves an orphan thread that cannot be opened, archived, or deleted #38965
   • [Regression][macOS Desktop] Orphaned “New task” sidebar entries cannot be archived or deleted #38724

   Powered by Codex Action
3. boombx403-byte commented on Aug 18, 2026

   

   boombx403-byte

   on Aug 18, 2026

   More actions

   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.
4. weathon commented on Aug 26, 2026

   

   weathon

   on Aug 26, 2026

   More actions

   if I pair both devices using method in this thread, it seems like I can use it without creating a ghost thread anymore.
5. nos1609 commented on Aug 28, 2026

   

   nos1609

   on Aug 28, 2026 – with ChatGPT Codex Connector

   More actions

   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.