[Regression][Remote Control] wait_threads rejects valid hostId until host discovery rehydrates the route #42331

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

26.831.21537 (build 7579)

What subscription do you have?

ChatGPT Pro 20x

What platform is your computer?

Controller: Darwin 25.6.0 arm64; target: Windows development host with a WSL-backed Codex task via Desktop Remote Control

What issue are you seeing?

Summary

codex_app.wait_threads can reject a valid Remote Control hostId while list_threads and read_thread resolve the same task through that exact host. Calling wait_threads once without hostId discovers the correct route; afterward the previously failing explicit-host call can work again.

This looks like a transient remote route-registry or hydration inconsistency, not task loss or failed remote execution.

Actual behavior

Errors include:

No Codex thread found for threadId: <redacted>.
Hosts without a readable match: local

On another occurrence the unreadable-host list contained both local and the exact Remote Control host, even though the task had just been readable. The task remained present and executed normally.

Impact

This breaks unattended orchestration. A coordinator can miss a completed result or stall while waiting for route hydration. Blindly retrying effectful work risks duplicate delivery, so safe coordinators must stop and reconcile state.

What steps can reproduce the bug?

1. Keep an existing Codex task on a connected Remote Control host; it may be idle with a completed turn.
2. Call list_threads and record its exact threadId and hostId=remote-control:<redacted>.
3. Call read_thread with those exact values. It succeeds and returns the task and completed turn.
4. Call wait_threads with the same values and a previously returned cursor.
5. Observe an immediate 'No Codex thread found' routing failure.
6. Call wait_threads with the same threadId and cursor but omit hostId.
7. It succeeds and returns the same task with the expected remote host, completed turn, result metadata and next cursor.
8. Repeat the explicit-host call. It can now succeed without any task, host, network, account or configuration change.

What is the expected behavior?

• A hostId returned by list_threads and accepted by read_thread should be accepted deterministically by wait_threads.
• Omitting hostId should not be required to initialize or repair the route.
• Temporary route unavailability should return a structured recoverable host error, not report that the task does not exist.
• Cached local routing must not override an explicit Remote Control host.

Additional information

Environment

• Controller: ChatGPT Desktop 26.831.21537, build 7579
• CLI visible on controller: codex-cli 0.152.1
• Controller OS: Darwin 25.6.0, Apple Silicon (arm64)
• Target: Windows development host with a WSL-backed Codex task via Desktop Remote Control
• Both devices use the same ChatGPT account and workspace
• First observed on 2026-09-02 UTC

All task IDs, host environment IDs, repository names, paths, prompts and user data are redacted.

Workaround

Call wait_threads without hostId for discovery, accept only an exact returned thread/host match, then use read_thread with the explicit host. Never blindly resend effectful work when discovery is missing or mismatched.

Related issues

• Remote SSH: codex_app.wait_threads has no registered handler while list/read/send remain healthy #40105 - wait_threads handler unavailable while list/read/send remain healthy
• Tasks orchestration is now broken when connected to a remote host #41295 - orchestration breaks after remote reconnect
• Remote Control created-thread card loses source host and opens child task on controller-local host #36969 - Remote Control route loses or rebases source host
• Remote Control threads created from MacBook are not visible in the host Mac mini Codex Desktop sidebar #41419 - inconsistent Remote Control thread discovery
• Codex Desktop: completed child turn visible in UI but read_thread returns items: [] #40014 - completed turn visible while task tools return empty items

This reproduction is narrower: the handler is present, the explicit host remains valid through other tools, and an unscoped discovery call makes the explicit-host wait route recover.

Exact redacted timestamps and private task/host identifiers can be provided to OpenAI maintainers if needed.