›_ Codex Issues
Codex Issues / #29262

Remote Control from macOS desktop drops Mac mini connection when opening remote threads

Open 💬 2 comments Opened Jun 20, 2026 by muinmomin

What version of the Codex App are you using?

Codex App 26.616.41845, bundle 4198
Bundled codex-cli / app-server: 0.142.0-alpha.6

Both controller Mac and host Mac mini appear to be on the same app version.

What subscription do you have?

Pro

What platform is your computer?

Controller Mac:

Darwin 25.5.0 arm64 arm

Host Mac mini:

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Remote Control from my laptop to my Mac mini connects successfully and initially works. I can add the remote Mac mini, add/open a remote Git project, and view remote MCP/config information.

However, when I open or switch remote threads from the laptop Codex desktop app, the remote connection drops and the Mac mini shows as offline. My phone can connect to the same Mac mini and open many remote threads quickly, but once the laptop opens a remote thread and triggers the failure, the phone connection also breaks.

Relevant controller-side log excerpts:

app_server_connection.closed code=4000 ... reason="remote control app-server stream became unknown" transport=websocket
Request failed ... method=thread/list ... "Codex app-server is not available"
Failed to resume conversation ... "Codex app-server is not available"
Codex app-server initialize handshake timed out

Relevant host-side log excerpt observed around the failure:

remote control websocket reader disconnected, err: failed to read from websocket: IO error: received fatal alert: BadRecordMac
remote control websocket writer was stopped
app-server remote control websocket connection cycle ended

There was also an earlier app-list payload issue: opening a remote thread triggered a roughly 2.1 MB app/list response containing thousands of connector/app entries. Disabling apps on the host reduced that payload and allowed one thread to open, but opening/switching additional threads still drops the connection.

What steps can reproduce the bug?

  1. On the host Mac mini, enable Codex App Remote Control.
  2. Add a remote Git project.
  3. From iPhone, connect to the Mac mini via Remote Control and open several threads. This works quickly.
  4. From laptop Codex App, go to Connections -> Control other devices.
  5. Connect to the same Mac mini.
  6. Add/open the same remote project.
  7. View remote MCP/config information. This works.
  8. Open a remote thread from the laptop. Sometimes the first thread opens.
  9. Open or switch to another remote thread.
  10. The laptop connection drops, the Mac mini appears offline, and the phone connection also breaks.

This was reproduced after cleaning stale local remote project state and after confirming there was no stale SSH-started app-server still running. This flow is using Remote Control, not SSH Remote.

What did you expect to happen?

The laptop Codex desktop app should behave like the phone client: opening or switching remote threads should not tear down the Mac mini's Remote Control websocket/app-server connection.

If the host websocket does drop or reconnect, the desktop client should recover cleanly instead of leaving pending thread/read/resume requests failing with Codex app-server is not available.

Additional information

No system proxy/VPN was obvious from scutil --proxy on either Mac.

Temporary workaround tried on the host:

[features]
apps = false
enable_mcp_apps = false

That changed app/list from roughly 2.1 MB to an empty response and improved the first thread open, but it did not fix the underlying Remote Control disconnect when opening/switching threads from the laptop.

Related but not exact issues found:

  • #24179 Remote Control goes offline while desktop WebSocket to chatgpt.com remains active
  • #23482 macOS remote control stalls: host app-server responsive but remote manager stays disconnected
  • #22773 iOS/macOS Remote Control broken after desktop update

No existing issue was found for the exact strings:

remote control app-server stream became unknown
BadRecordMac

View original on GitHub ↗

2 Comments

Necmttn · 2 months ago

Remote thread open should emit a connection lifecycle receipt. Include controller host id, remote host id, project id, thread id, stream id, last heartbeat, close code, close reason, and whether the phone/laptop clients shared the same remote app-server stream. That would make "remote became unknown" diagnosable instead of a generic offline transition.

---

_Generated with ax._

ranlabs · 1 month ago

Additional macOS reproduction observed on 2026-07-15.

Environment

  • ChatGPT/Codex desktop app: 26.707.72221 (bundle 5307)
  • macOS 26.5.2 (25F84), arm64
  • Bundled local app-server reported version 0.144.2
  • macOS desktop controller connecting to another Mac through Remote Control (not SSH)
  • No system proxy configured; Tailscale was disconnected
  • Ethernet was the primary/default route; Wi-Fi was also enabled

Behavior

The app repeatedly showed Reconnecting. Restarting the desktop app did not immediately recover the remote connection.

The local stdio app-server started and initialized successfully in about 2.6 seconds, while the Remote Control WebSocket failed separately:

2026-07-15T09:40:27Z remote_control_websocket.connect_failed_before_open:
Unexpected server response: 520

2026-07-15T09:41:05Z app_server_connection.fail:
Codex app-server initialize handshake timed out
transport=websocket
progress previously reached waiting-for-device

The connection then repeated 30-second initialize-handshake timeouts and reconnect attempts until it recovered without a configuration change:

2026-07-15T09:48:46Z remote_connections.connection_state_changed
state=connected
error=null

Total observed failure window was approximately 8 minutes (19:40–19:48 AEST / 09:40–09:48 UTC).

Network checks during/after the incident

  • Local gateway: 12/12 replies, 0% packet loss
  • Public endpoint (1.1.1.1): 20/20 replies, 0% packet loss
  • chatgpt.com HTTP/2/TLS connection completed successfully through both Ethernet and Wi-Fi
  • One ERR_NETWORK_CHANGED entry appeared during the retry window, but the repeated server HTTP 520 plus subsequent waiting-for-device handshake timeouts look consistent with a Remote Control relay/backend or remote app-server recovery problem rather than a complete local network outage

Host IDs, account IDs, thread IDs, and request IDs are intentionally omitted. Sanitized logs can be provided if useful.