[macOS] Mac-to-Mac Remote Control fails with “Opening handshake has timed out” while iPhone connects successfully

Resolved 💬 0 comments Opened Jul 18, 2026 by sanhuo2020 Closed Jul 18, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.31925

What subscription do you have?

Plus

What platform is your computer?

_No response_

What issue are you seeing?

Description

I am experiencing a consistent Mac-to-Mac Remote Control failure between two Apple Silicon Mac minis.

The controlling Mac can discover and add the host Mac successfully. The host appears in:

Settings → Connections → Control other devices

However, enabling the connection always fails with:

Connection failed · Opening handshake has timed out

Remote Control from the ChatGPT iPhone app to the same host works immediately and reliably.

Environment

Host

Device: Mac mini M4
Role: Remote Control host
ChatGPT/Codex desktop app version: 26.715.31925
* macOS version: 26.3.1
Architecture: Apple Silicon / arm64
Host remains awake and the desktop app remains open
Remote Control is enabled under Control this Mac

Controller

Device: Mac mini M2
Role: Device attempting to control the M4 host
ChatGPT/Codex desktop app version: 26.715.31925
macOS version: 15.7.4
Architecture: Apple Silicon / arm64
Standalone Codex CLI: 0.144.5, installed through Homebrew

Account and network

Subscription: ChatGPT Plus
Both Macs are signed into the same ChatGPT account and workspace
Both Macs are on the same local network
The result is unchanged after removing and re-adding the connection
The two Macs have different ~/.codex/installation_id hashes, so this does not appear to be the cloned/Migration Assistant identity issue described in another comment

Steps to reproduce

Open the ChatGPT/Codex desktop app on the M4 host.
Go to Settings → Connections → Control this Mac.
Enable Remote Control and allow other devices to connect.
Keep the M4 awake and leave the desktop app running.
Open the desktop app on the M2 controller.
Go to Settings → Connections → Control other devices.
Add the M4 host.
Confirm that the M4 appears in the device list.
Enable the connection.
Wait for the connection attempt to complete.

Actual behavior

The M4 is discovered and displayed in the device list, but the connection fails after waiting for the opening handshake:

Connection failed · Opening handshake has timed out

Removing the device, pairing it again, restarting both apps, and restarting the Macs do not resolve the problem.

Expected behavior

The M2 desktop app should connect to the M4 host and allow access to the host’s projects, chats, files, tools, and running work, in the same way that the ChatGPT iPhone Remote interface can connect to the M4.

Important control test

The ChatGPT iPhone app connects successfully to the same M4 host.

This suggests that the following components are functioning:

The M4 Remote Control host service
The ChatGPT account and workspace authorization
Host registration and device pairing
The host-to-relay connection
The M4’s availability and sleep settings

The failure appears specific to the macOS desktop-to-desktop Remote Control path.

Connectivity diagnostics

I ran:

codex doctor --all

M2 controller result

Codex Doctor v0.144.5 · macos-aarch64

Connectivity
  network: proxy environment readable
  websocket: connected
  handshake result: HTTP 101 Switching Protocols
  endpoint: wss://chatgpt.com/backend-api/<redacted>
  DNS: 1 IPv4, 0 IPv6, first IPv4
  reachability: ChatGPT backend reachable

M4 host result

Connectivity
  websocket: connected
  handshake result: HTTP 101 Switching Protocols
  DNS: 1 IPv4, 0 IPv6, first IPv4
  reachability: ChatGPT backend reachable

Therefore, the failure does not appear to be caused by a broken IPv6 route or a general inability to establish ChatGPT WebSocket connections.

The standalone CLI reports app-server not running (ephemeral mode) on both machines, but the desktop app’s managed Remote Control host is clearly active because the iPhone can connect successfully.

Troubleshooting already attempted

Confirmed both desktop apps use the same version: 26.715.31925
Confirmed both Macs use the same ChatGPT account and workspace
Fully quit and reopened both desktop apps
Restarted both Macs
Removed and re-added the remote connection
Disabled and completely quit Tailscale
Kept the M4 awake and online
Verified normal ChatGPT HTTPS connectivity
Verified WebSocket connectivity with HTTP 101 Switching Protocols
Verified that both machines resolve the ChatGPT endpoint using IPv4, not IPv6
Reinstalled and updated the standalone Codex CLI on the M2 to 0.144.5
Compared ~/.codex/installation_id hashes on both Macs and confirmed they are different
Confirmed that iPhone → M4 Remote Control works

Additional observations

The desktop controller successfully receives enough Remote Control state to discover and display the M4 host. The failure occurs only when it attempts to open the remote connection.

This may indicate a problem in one of the following areas:

macOS desktop Remote Control client state
Remote Control WebSocket or app-server stream initialization
Desktop-to-desktop enrollment handling
Connection registry or host ID hydration
A desktop-specific handshake path that differs from the iPhone client

I am not claiming a specific root cause, but the successful iPhone connection and successful general WebSocket diagnostics appear to rule out a basic host, account, LAN, IPv6, or general WebSocket connectivity failure.

Related issue

This appears closely related to:

https://github.com/openai/codex/issues/27231

Request

Could the team please investigate the macOS desktop-to-desktop Remote Control handshake path?

What steps can reproduce the bug?

This is a desktop-to-desktop Remote Control bug and is not triggered by a code snippet or a model conversation. The connection fails before any remote session or thread can be opened.

Steps to reproduce

Install ChatGPT/Codex desktop app version 26.715.31925 on two Apple Silicon Macs.
Sign in to both Macs using the same ChatGPT account and workspace.
On the Mac mini M4 host, open:

Settings → Connections → Control this Mac

Enable Remote Control and allow other devices to connect.
Keep the M4 awake, online, and leave the desktop app running.
On the Mac mini M2 controller, open:

Settings → Connections → Control other devices

Add the M4 host.
Confirm that the M4 appears in the device list.
Enable the connection.
Wait for the opening handshake.

Actual result

The M4 is discovered successfully, but the connection fails with:

Connection failed · Opening handshake has timed out

Expected result

The M2 desktop app should connect to the M4 and display the host’s projects, chats, and running work.

Control test

The ChatGPT iPhone app connects successfully to the same M4 host using the same ChatGPT account and workspace.

Both Macs also pass the Codex WebSocket diagnostic:

codex doctor --all

Relevant result on both machines:

websocket: connected
handshake result: HTTP 101 Switching Protocols
DNS: 1 IPv4, 0 IPv6, first IPv4

The issue therefore appears specific to the macOS desktop-to-desktop Remote Control handshake path.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗