[macOS] CLI 0.144.6 hangs indefinitely spawning codex-security MCP; Esc and timeout are ineffective

Reproduce the macOS arm64 hang with Codex CLI 0.144.6 and the codex-security MCP server, then inspect the rmcp::transport::child_process::TokioChildProcessBuilder::spawn and process_wrap::tokio::core::CommandWrap::spawn paths. Trace how the synchronous read interacts with startup timeout and Esc cancellation. Done means MCP startup either completes or returns an actionable timeout, and Esc reliably cancels it.

Summary

On macOS arm64, Codex CLI 0.144.6 can hang indefinitely while starting the codex-security MCP server:

Starting MCP servers (5/6): codex-security (... • esc to interrupt)

The session never becomes usable. Pressing Esc does not interrupt startup, and the startup timeout is not enforced. The affected process remained stuck for more than 23 minutes.

Environment

• macOS 26.5.2 (build 25F84), arm64
• Codex CLI: codex-cli 0.144.6
• Codex Security plugin: 0.1.13
• Node.js: v22.23.1
• Launch command: codex --dangerously-bypass-approvals-and-sandbox

The PATH-resolved CLI is managed by an external local runtime (Orca), but the hang occurs inside Codex's MCP child-process startup path.

Steps to reproduce

1. Install/enable the Codex Security plugin.
2. Launch Codex CLI in a repository:

   codex --dangerously-bypass-approvals-and-sandbox
   

3. Observe startup stop at Starting MCP servers (5/6): codex-security.
4. Press Esc or wait beyond the configured/default MCP startup timeout.

Actual behavior

• Startup remains stuck indefinitely.
• Esc does not cancel.
• No codex-security child process appears under the Codex process.
• Other MCP child processes are present and idle.
• The CLI process remains alive but the session cannot be used.

Expected behavior

Codex should either:

• successfully spawn and initialize the MCP server, or
• fail within the startup timeout with an actionable error.

Esc should always cancel MCP startup.

Diagnostic evidence

Repeated macOS process samples showed a Tokio worker blocked in the MCP child-process spawn path:

rmcp::transport::child_process::TokioChildProcessBuilder::spawn
process_wrap::tokio::core::CommandWrap::spawn
read (libsystem_kernel.dylib)

The codex-security process itself had not been created, so the hang occurs before the MCP initialize handshake.

I also launched the exact plugin entrypoint directly and sent an MCP initialize request. It returned a valid response within five seconds with no stderr, which suggests that the plugin runtime itself is healthy.

As a version comparison, the Codex CLI bundled with the desktop app (0.146.0-alpha.3.1) completed MCP startup and reached the prompt in about ten seconds using the same repository and configuration.

This suggests the child-process spawn operation in 0.144.6 can block in a synchronous read() that is not covered by the MCP startup timeout or cancellation path.

Related issue

Related to #20167, but this appears to be a distinct failure mode: #20167 reports a codex_apps handshake/network timeout, whereas here the local codex-security child process is never spawned and the CLI is blocked inside the spawn implementation.