Repository navigation
Remote Control from macOS desktop drops Mac mini connection when opening remote threads #29262
Description
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?
- On the host Mac mini, enable Codex App Remote Control.
- Add a remote Git project.
- From iPhone, connect to the Mac mini via Remote Control and open several threads. This works quickly.
- From laptop Codex App, go to Connections -> Control other devices.
- Connect to the same Mac mini.
- Add/open the same remote project.
- View remote MCP/config information. This works.
- Open a remote thread from the laptop. Sometimes the first thread opens.
- Open or switch to another remote thread.
- 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 = falseThat 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:
- Remote Control goes offline while desktop WebSocket to chatgpt.com remains active #24179 Remote Control goes offline while desktop WebSocket to chatgpt.com remains active
- macOS remote control stalls: host app-server responsive but remote manager stays disconnected #23482 macOS remote control stalls: host app-server responsive but remote manager stays disconnected
- iOS/macOS Remote Control broken after desktop update: host online, mobile 403/offline/stale Plan state #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
Activity
Necmttn commentedon Jun 21, 2026
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 commentedon Jul 15, 2026
Additional macOS reproduction observed on 2026-07-15.
Environment
26.707.72221(bundle5307)26.5.2(25F84), arm640.144.2Behavior
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:
The connection then repeated 30-second initialize-handshake timeouts and reconnect attempts until it recovered without a configuration change:
Total observed failure window was approximately 8 minutes (19:40–19:48 AEST / 09:40–09:48 UTC).
Network checks during/after the incident
chatgpt.comHTTP/2/TLS connection completed successfully through both Ethernet and Wi-FiERR_NETWORK_CHANGEDentry appeared during the retry window, but the repeated server HTTP 520 plus subsequentwaiting-for-devicehandshake timeouts look consistent with a Remote Control relay/backend or remote app-server recovery problem rather than a complete local network outageHost IDs, account IDs, thread IDs, and request IDs are intentionally omitted. Sanitized logs can be provided if useful.
LiuLawrence45 commentedon Oct 12, 2026
Still observed this is so annoying genuinely