codex - 💡(How to fix) Fix macOS remote control stalls: host app-server responsive but remote manager stays disconnected [2 comments, 3 participants]

What version of the Codex App are you using?

Host Mac Studio:

• Codex App: 26.513.31313 / bundle 2867
• Bundled CLI: codex-cli 0.131.0-alpha.9
• PATH CLI: /opt/homebrew/bin/codex, codex-cli 0.125.0

What platform is your computer?

Host:

• Mac Studio, Mac13,2, Apple M1 Ultra, 64 GB RAM
• macOS 26.4.1, build 25E253

Client surfaces where the problem has been observed:

• ChatGPT iPhone app using Codex Remote Control
• A separate MacBook Codex app using Connections / Remote Control to connect to the Mac Studio host

What issue are you seeing?

Codex Remote Control / remote connections are extremely slow or fail to become usable when connecting to a Mac Studio host.

The latest concrete reproduction was on 2026-05-19 21:57 JST, after switching the Mac Studio host to wired Ethernet. From a MacBook Codex app, I opened Connections and selected the Mac Studio host. After tens of seconds, the remote session still did not become usable and the thread list did not appear.

This also matches the earlier iPhone ChatGPT app behavior: connecting to the same Mac Studio host is very slow, unstable, or disconnects. In contrast, MacBook -> Tailscale -> Screen Sharing to the same Mac Studio is comparatively stable, so the Mac Studio itself appears reachable and the problem seems specific to Codex Remote Control / relay / remote state propagation.

What steps can reproduce the bug?

1. Start Codex App on the Mac Studio host.
2. Ensure the Mac Studio is reachable and signed into Codex.
3. From another device, open Codex Remote Control:
   • ChatGPT iOS app -> Codex remote connection, or
   • another macOS Codex app -> Connections -> select the Mac Studio host.
4. Open the host/thread list or try to open a remote Codex thread.
5. Observe that the remote connection is extremely slow, stalls, or does not populate threads after tens of seconds.

What is the expected behavior?

Remote Control should connect promptly, show the host thread list, and stream updates reliably for simple thread operations. It should not leave the client waiting indefinitely while the host app-server is responsive.

Host-side evidence from the Mac Studio

I collected sanitized Mac Studio-side logs around the 2026-05-19 21:57 JST repro window. I am not attaching full logs because they may include private session metadata. The relevant excerpt is below.

The host app-server initialized normally:

2026-05-19 21:55:04.581 JST info [AppServerConnection]
  initialize_handshake_result durationMs=313 outcome=success transportKind=stdio

2026-05-19 21:55:04.581 JST info [AppServerConnection]
  app_server_connection.state_changed ... hostId=local ... previous=connecting next=connected ... transport=stdio

The Mac Studio host discovered one remote-control connection entry, but the manager state stayed disconnected:

2026-05-19 21:55:06.589 JST info [remote-connections/window-context]
  refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=1 previousConnectionCount=0

2026-05-19 21:55:06.631 JST info [electron-message-handler]
  remote_connections.manager_state_set hostId=remote-control:<redacted-env-id>
  previousState=disconnected nextState=disconnected previousError=null nextError=null
  source=bootstrap_connection_state_fetch

During the time when the remote client was not becoming usable, local app-server RPCs on the host were still fast:

2026-05-19 21:57:23.405 JST info [AppServerConnection]
  response_routed method=thread/read durationMs=2 errorCode=null

2026-05-19 21:57:23.619 JST info [AppServerConnection]
  response_routed method=thread/resume durationMs=79 errorCode=null

2026-05-19 21:57:47.969 JST info [AppServerConnection]
  response_routed method=thread/list durationMs=125 errorCode=null

2026-05-19 21:58:05.369 JST info [AppServerConnection]
  response_routed method=thread/start durationMs=404 errorCode=null

Suspicious state/indexing lines also appeared:

2026-05-19 21:58:05.835 JST error [electron-message-handler]
  Received turn/started for unknown conversation conversationId=<redacted-conversation-id>

2026-05-19 21:58:10.746 JST error [electron-message-handler]
  Received turn/completed for unknown conversation conversationId=<redacted-conversation-id>

The remote connection inventory continued to see one connection, but I did not find a later connected state transition in the Mac Studio host log:

2026-05-19 21:59:07.395 JST info [remote-connections/window-context]
  refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=1 previousConnectionCount=1

2026-05-19 21:59:08.252 JST info [remote-connections/window-context]
  refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=1 previousConnectionCount=1

2026-05-19 21:59:09.163 JST info [remote-connections/window-context]
  refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=1 previousConnectionCount=1

I did not find clear Mac Studio host-side log evidence in this repro window for:

• WebSocket close code 1006
• websocket closed
• transport_closed
• CodexClientError
• explicit request timeout / timed out
• a reconnect loop after 21:57 JST

The 1006 hits in macOS unified logs were unrelated RunningBoard assertion IDs, not WebSocket close code 1006.

Network evidence

At the time of the latest repro, the Mac Studio was on wired Ethernet:

Current default route at 22:00 JST:
  interface=en0
  hardware port=Ethernet

Quick ping checks from the Mac Studio were clean:

Gateway ping at 22:01 JST:
  10 packets transmitted, 10 received, 0.0% packet loss
  rtt min/avg/max/stddev = 0.439/0.644/1.322/0.247 ms

External ping to 1.1.1.1 at 22:01 JST:
  10 packets transmitted, 10 received, 0.0% packet loss
  rtt min/avg/max/stddev = 3.400/3.996/4.742/0.360 ms

networkQuality -v earlier the same day did not indicate an obvious host-wide connectivity outage.

Interpretation

This does not look like a basic LAN/WAN packet-loss problem on the Mac Studio and does not look like the local host app-server being stalled. The host app-server was responsive, but Remote Control did not become usable from the client side.

The strongest host-side clue is that a remote-control connection entry was discovered, but the remote connection manager remained disconnected, with no later connected transition found in the Mac Studio host log. This suggests a problem in Codex Remote Control state sync, relay/WebSocket path, or client-to-host connection handling.

The unknown conversation and repeated remote task ownership warnings may be related to thread/task state not hydrating correctly once the remote path is partially present.

Related issues checked

This may be related to the broader Remote Control state-propagation problems in #22773 and daemon/discovery mismatch in #23403, but this report adds a Mac Studio host-side log window and an app-to-app macOS remote reproduction where the host app-server is fast while the remote manager remains disconnected.

Additional information

I intentionally did not include full logs, session transcripts, repo-specific private content, API keys, tokens, cookie values, host IDs, conversation IDs, request IDs, IP addresses, or local user names. I can provide additional sanitized excerpts if useful.