`remote-control pair` times out after 2s while backend pairing request allows 30s

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

Not applicable; this occurs before starting a model turn.

What platform is your computer?

Linux 7.0.14-9-pve x86_64 x86_64

Ubuntu 24.04 guest.

What terminal emulator and version are you using (if applicable)?

SSH session; TERM=screen.xterm-256color.

Codex doctor report

Privacy-trimmed to the relevant checks:

{
  "schemaVersion": 1,
  "overallStatus": "fail",
  "codexVersion": "0.147.0",
  "checks": {
    "app_server.status": {
      "status": "ok",
      "summary": "background server is running",
      "details": {"app-server version": "0.147.0", "mode": "persistent", "status": "running"}
    },
    "auth.credentials": {
      "status": "ok",
      "summary": "auth is configured",
      "details": {"stored ChatGPT tokens": "true", "stored auth mode": "chatgpt"}
    },
    "network.env": {
      "status": "ok",
      "details": {"proxy env vars present": "HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY, http_proxy, https_proxy, all_proxy, no_proxy"}
    },
    "network.provider_reachability": {
      "status": "fail",
      "summary": "one or more required provider endpoints are unreachable over HTTP",
      "details": {"ChatGPT base URL": "request timed out (required)"},
      "durationMs": 3017
    },
    "network.websocket_reachability": {
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded",
      "details": {"handshake result": "HTTP 101 Switching Protocols"},
      "durationMs": 5329
    },
    "installation": {
      "status": "ok",
      "summary": "installation looks consistent",
      "details": {"install context": "standalone", "platform": "linux-x86_64", "version": "0.147.0"}
    }
  }
}

What issue are you seeing?

codex remote-control start --json succeeds and reports a connected daemon, but codex remote-control pair consistently fails at almost exactly two seconds:

$ time codex remote-control pair
Error: timed out waiting for remoteControl/pairing/start response

Caused by:
    deadline has elapsed

real    0m2.023s
user    0m0.001s
sys     0m0.008s

The local app-server receives remoteControl/pairing/start, performs the backend HTTPS request, and completes shortly after the daemon CLI client disconnects. Representative debug trace:

12:40:07.807 remoteControl/pairing/start received
12:40:07.820 connecting to chatgpt.com through HTTP proxy
12:40:09.924 pairing handler completes
12:40:09.924 dropping message for disconnected connection

The handler needed about 2.117 seconds, while the caller stopped waiting after 2 seconds.

A minimal WebSocket-over-UDS diagnostic client using a 15-second response timeout successfully received valid pairingCode and manualPairingCode fields from the same app-server. This confirms that authentication, enrollment, the pairing endpoint, and response parsing work when the local caller waits long enough.

Relevant source:

• generic 2-second control-socket response timeout
• pairing waits using that timeout
• backend pairing request permits 30 seconds
• PR #29913 introduced the daemon pairing command; its unit test returns immediately and does not exercise backend or proxy latency.

Current main still defines CONTROL_SOCKET_RESPONSE_TIMEOUT as two seconds.

What steps can reproduce the bug?

1. Authenticate the CLI using ChatGPT.
2. Use a functioning HTTP proxy with approximately 2-3 seconds of ChatGPT request latency. The daemon inherits all upper- and lowercase proxy variables.
3. Run RUST_LOG=debug codex remote-control start --json.
4. Confirm it reports "status":"connected".
5. Run time codex remote-control pair --json.
6. Observe that it exits after approximately 2.02 seconds.
7. Inspect the daemon log and observe that the pairing handler completes later and drops its response because the Unix-socket client disconnected.

This reproduces consistently. Authenticated model-list HTTP requests and Remote Control WebSocket handshakes succeed through the same proxy.

What is the expected behavior?

codex remote-control pair should wait long enough for the pairing backend operation to finish and print the short-lived pairing code.

Pairing should use a dedicated response timeout longer than the backend request timeout rather than the generic two-second control-socket probe timeout. Since the backend allows 30 seconds, a slightly longer caller timeout would also allow backend timeout errors to propagate instead of masking them as a local control-socket timeout.

Additional information

Repeated CLI retries can leave pairing handlers running after each caller disconnects. Because pairing requests are serialized, retries can queue more pairing operations and make later attempts slower.

No exact existing issue was found for the error string, remoteControl/pairing/start, or CONTROL_SOCKET_RESPONSE_TIMEOUT. Related mobile pairing reports exist, but this report is intentionally limited to the independently reproduced CLI timeout.

Error: timed out waiting for remoteControl/pairing/start response

Caused by:
    deadline has elapsed