Remote 0.2.50 / ChatGPT: broadcast_v1 calls complete locally in ~2s but results return 15–38s later

Summary

With Desktop Commander Remote 0.2.50 used from ChatGPT/Codex over broadcast_v1, tool calls are delivered to the device and complete locally in about 2–3 seconds, but the completed result can take another 15–30+ seconds to reach the client.

This is not a pure network RTT measurement. The timings below split the call at the timestamp contained in Desktop Commander's own pong result.

Environment

• Desktop Commander: 0.2.50 (latest npm release at the time of testing)
• Node.js: 22.23.2
• Client: openai-mcp (Codex) 1.0.0
• Transport: broadcast_v1
• OS: Linux (Ubuntu/GNOME)
• Authentication valid; device reported online
• Remote get_config also succeeds end to end

Reproduction

Invoke the Remote ping tool repeatedly from ChatGPT/Codex and compare:

1. wall-clock time immediately before the tool call,
2. the timestamp returned inside pong,
3. wall-clock time when the tool result becomes available to the client.

Measurements

A separate three-call batch measured total durations of 32.476 s, 27.398 s, and 30.980 s.

Debug evidence

A temporary remote --debug run showed a healthy subscription and successful local completion:

[DEBUG] Channel subscription status: SUBSCRIBED
[DEBUG] Doorbell received for call: <redacted>
Received tool call <redacted>: ping {} metadata:
  {"transport":"broadcast_v1",
   "clientInfo":{"name":"openai-mcp (Codex)","version":"1.0.0"},
   "device_app_version":"0.2.50"}
[DEBUG] Call marked executing
Tool call ping completed: pong 2026-09-16T10:53:53.059Z
[DEBUG] Call result updated successfully
[DEBUG] Result doorbell sent

For that call, the external tool result did not become available until 2026-09-16T10:54:22.878Z, about 29.8 seconds after the local pong.

There were no channel errors or local execution errors. In a separately polled fast run, the database row reached completed promptly and was then consumed/deleted, which is consistent with local execution and result persistence working.

A/B against current main behavior

The installed 0.2.50 code explicitly calls notifyResult(). Current main appears to rely on the database trigger to notify the server instead.

I temporarily aligned the installed files with that current-main behavior and repeated the same measurement:

So removing the explicit result doorbell produced one fast result but did not eliminate the high variability. The temporary change was reverted; the installation is back to unmodified 0.2.50.

Expected behavior

Once the tool has completed locally and the result has been persisted/notified, the result should reach the ChatGPT/Codex client promptly and consistently.

Actual behavior

The call is received and completed locally in ~2–3 seconds, while the result-return phase intermittently stalls for roughly 15–38 seconds.

Relation to #660

This appears related to the same ChatGPT Remote MCP / broadcast_v1 transport family, but it is a different symptom from #660:

• #660 describes individual inbound calls being dropped/absent from device logs.
• Here, every tested call is delivered, executed, persisted, and logged successfully; only the completed result is delayed before the client receives it.

The evidence points to the post-completion relay/result-return path, but I cannot determine from the client-side test whether the delay is in the hosted relay, subscription delivery, or client polling/consumption.