Remote SSH: `codex_app.wait_threads` has no registered handler while list/read/send remain healthy

What issue are you seeing?

In a Codex Desktop workflow using a Remote SSH host, codex_app.wait_threads is exposed to the coordinator but consistently fails immediately with:

No handler registered for tool: codex_app.wait_threads

Other task-control operations remain healthy in the same session:

• list_threads: succeeds
• read_thread: succeeds
• send_message_to_thread: succeeds on real task dispatches
• underlying tasks continue executing normally
• wait_threads: fails with the missing-handler error

This materially impacts unattended coordinator/subagent workflows because the coordinator can dispatch and inspect work but cannot use the advertised wait primitive.

Environment

Remote host:

• Ubuntu 24.04 LTS
• x86_64
• Remote SSH through Codex/ChatGPT Desktop

Codex:

• CLI: codex-cli 0.149.0
• remote app-server: 0.149.0
• npm installation
• npm 11.12.1
• ChatGPT authentication
• OpenAI provider / Responses API

Desktop controller:

• Windows Codex/ChatGPT Desktop
• updated to the latest version offered by the application
• fully restarted before the final reproduction

codex doctor after update/restart reported:

• app-server running
• websocket connected
• provider endpoints reachable
• state databases healthy / integrity OK
• configuration/auth healthy
• 0 failures

Clean reproduction

1. Update the Remote SSH host's Codex CLI to 0.149.0.
2. Verify codex --version reports codex-cli 0.149.0.
3. Fully restart the Windows desktop controller.
4. Verify with codex doctor that the remote app-server is also 0.149.0.
5. Ensure no second desktop controller is connected to the remote environment.
6. Verify only one remote-host identity is visible.
7. Use existing real tasks rather than synthetic work.
8. Call task listing and reading: both succeed.
9. Call wait_threads for an existing healthy task.
10. Observe:

No handler registered for tool: codex_app.wait_threads

11. Use the next naturally required send_message_to_thread dispatch; it succeeds.

The target task remains healthy and readable, so this does not appear to be a crashed-task failure.

Expected behavior

If wait_threads is exposed as an available task-control tool, its handler should be registered and callable for the active session.

If the handler cannot be registered, tool discovery should omit the tool or return a structured recoverable availability error rather than exposing a callable-looking tool that deterministically returns No handler registered.

Actual behavior

wait_threads is exposed but fails immediately because no handler is registered, while list/read/send operations continue working against the same task environment.

Prior behavior

The same failure was previously observed on CLI/app-server 0.147.0.

On that version, send_message_to_thread could also intermittently time out while task listing/reading and the underlying tasks remained healthy. Restarting the desktop controller temporarily restored task control on one occasion, but the failure later returned during extended unattended execution.

After updating the CLI, remote app-server, and desktop controller, message dispatch is currently healthy on 0.149.0, but the wait_threads missing-handler failure remains reproducible.

Controller / host cleanup performed

A second desktop application had previously been open, so that was explicitly eliminated as a variable before the final reproduction:

• second desktop application fully quit
• Windows remained the sole desktop controller
• one remote-host identity visible
• wait_threads still failed identically

Impact

This prevents reliable unattended multi-task coordination. A coordinator can dispatch work and inspect task state but cannot use the normal wait primitive, requiring degraded-mode polling/reconciliation logic to avoid stalling otherwise healthy work.

Current workaround

The coordinator currently:

1. attempts the wait operation once;
2. uses list/read to inspect state;
3. does not repeatedly retry the broken wait handler;
4. continues using message dispatch where possible;
5. safely reconstructs stateless work when necessary;
6. continues unrelated work rather than treating the missing handler as a global stop.

Additional diagnostic observation

codex doctor reports a warning that a small number of rollout files are missing from the state DB, while the state and thread-history databases themselves report integrity OK. I do not know whether this is related, but am mentioning it because the observed failure concerns thread/task control.

No raw logs, task IDs, hostnames, usernames, repository names, project names, local paths, credentials, external-service names, or prompt contents are included in this report.

Related reports appear to include #28080 and #36013, but this reproduction is specifically wait_threads on a current 0.149.0 Remote SSH CLI/app-server with list/read/send remaining healthy.

Start at the app-server entry point that exposes and registers codex_app.wait_threads, comparing it with the healthy list_threads, read_thread, and send_message_to_thread operations. Reproduce against CLI/app-server 0.149.0 using the documented Remote SSH steps; done means the wait operation is callable, or discovery omits it or returns a structured availability error, with a regression test.