Codex Desktop app-control tools can hang without a terminal response

Summary

Codex Desktop app-control tools can hang indefinitely without returning either a result or a structured error. In the reproduced state, global thread listing, exact thread reading, cross-thread follow-up, and thread handoff all stalled. The requests did not reach the local app-server message processor.

Environment

• macOS arm64
• Codex Desktop 26.818.31338 (bundle 6892)
• bundled CLI 0.149.0-alpha.4
• bundled codex-app-tools 0.1.0
• Apps enabled
• Full-access local configuration

Reproduction

1. From a running Codex Desktop control thread, invoke any of:
   • list threads with a one-item limit;
   • read a known local thread;
   • send a follow-up to a known local thread;
   • hand off a known local thread to a configured SSH host.
2. Wait 60 to 90 seconds.
3. The call remains pending and produces no operation ID, result, or structured failure.

The same result occurs when the local host ID is supplied explicitly. A bounded direct tools/list probe against the app-tools native pipe also connects but receives no response.

Control evidence

• The local Codex state database passes quick_check.
• The main app-server remains alive and continues to process ordinary turn events.
• Local filesystem, network, GitHub, and SSH diagnostics continue to work.
• The failed app-control calls do not appear as thread/read, thread/list, send, or handoff requests in the app-server message processor logs.
• A supported CLI continuation of a terminal destination thread reports that the transcript still has an active writer, and the main Desktop app-server is the process retaining that transcript.
• The bundled app-tools native-pipe client waits for a tools/call response and has no internal request deadline. It only clears a pending request if the outer abort signal fires or the socket closes.

This points to request delivery or response return in the Desktop host/native-pipe bridge, rather than a destination-thread lock, remote SSH failure, database corruption, or sandbox denial.

Expected behavior

Every app-control request should terminate with either:

1. a success receipt containing a correlation or operation ID, or
2. a bounded structured timeout or connection-closed error proving whether mutation occurred.

On host-bridge loss, the client should send tools/cancel, reject the pending promise, and release any stale thread-writer custody. The tool timeout should be short enough to prevent minute-scale or hour-scale ambiguous hangs.

Suggested regression matrix

• list_threads, exact read_thread, cross-thread send, and handoff;
• local destination and configured remote SSH destination;
• idle destination and terminal-but-loaded destination;
• host bridge healthy, disconnected, and reconnected;
• verify a bounded structured error and no ambiguous partial mutation;
• verify a terminal destination can subsequently be resumed by the supported CLI.

Related but distinct: #15310 tracks Desktop sandbox/permission propagation. This report concerns app-control transport liveness and terminal-response guarantees.

Start by tracing the bundled app-tools native-pipe client, the tools/call request path, and the Desktop app-server message processor to determine where delivery or response return stops. Exercise list_threads, read_thread, cross-thread send, and handoff across the listed host and destination states. Done means every request returns a success receipt or bounded structured error, sends tools/cancel when needed, and does not leave ambiguous thread-writer custody.