[macOS][Remote Control] Repeated WebSocket 503 through YUL; Allow connections fails (26.903.61454)

What version of the Codex App are you using?

• ChatGPT/Codex desktop: 26.903.61454, build 8378
• Bundled app-server: codex-cli 0.153.4
• Bundle identifier: com.openai.codex

What subscription do you have?

Signed in using a ChatGPT account; subscription tier not included in this report.

What platform is your computer?

macOS 26.6.2, Apple Silicon arm64.

What issue are you seeing?

In Settings > Connections > Control this Mac, enabling Allow connections fails. The French UI shows:

Impossible de mettre à jour la disponibilité du contrôle à distance

The toggle is off in the resulting error state. The corresponding English message is “Couldn't update remote control availability”.

The underlying Remote Control WebSocket repeatedly receives HTTP 503 Service Unavailable from:

wss://chatgpt.com/backend-api/wham/remote/control/server

This report adds an affected macOS host with failing responses routed through Cloudflare YUL, in addition to the similar reports linked below.

What steps can reproduce the bug?

1. Open the desktop app while signed in.
2. Open Settings > Connections > Control this Mac.
3. Turn on Allow connections.
4. Observe the error toast and the toggle remaining/returning off.
5. Inspect the Remote Control transport logs: the connection continues retrying with HTTP 503.

What is the expected behavior?

The enrolled desktop host should connect to the Remote Control service and remain available for pairing and remote access. If the service cannot establish the connection, the UI should provide an actionable error rather than only reporting that availability could not be updated.

Additional information

Verified on this host

• The desktop log records remoteControl/enable with errorCode=null at 2026-09-10T02:50:47.532Z and 2026-09-10T02:51:00.566Z, while the user sees an activation error.
• The transport recognizes an existing enrollment: has_enrollment=true, with a server ID and environment ID present.
• Repeated WebSocket 503 failures were observed during this session, including the fresh sample below at 2026-09-09 23:00:34 America/Toronto.
• Local agent work, shell tools and public web requests continue to function while this Remote Control connection fails.

Sanitized transport excerpt from ~/.codex/logs_2.sqlite:

failed to connect to app-server remote control websocket
websocket_url=wss://chatgpt.com/backend-api/wham/remote/control/server
installation_id=<redacted>
server_name=<redacted>
HTTP error: 503 Service Unavailable
request-id: <none>
cf-ray: a38b2ee0793def5d-YUL
body: upstream connect error or disconnect/reset before headers.
reset reason: connection termination
error_kind=Other
reconnect_attempt=10
reconnect_delay=30s
reconnect_backoff_reset=true
has_enrollment=true
server_id=Some("<redacted>")
environment_id=Some("<redacted>")
subscribe_cursor_present=false

This is a read-only diagnosis. We have not tested a different network on this host, reset enrollment, changed proxy/VPN settings, or reinstalled the app as part of this investigation. The evidence identifies the failing connection; it does not establish the exact server-side or network-path cause.

Related reports

• #44326 — macOS, same desktop version and matching WebSocket 503.
• #44358 — macOS, matching 503 through GRU.
• #44384 — Windows, enrollment succeeds but the same WebSocket returns 503.
• #44366 — matching errors with network-path-dependent recovery.
• #44313 — Linux, matching upstream connection termination.

Please correlate the timestamp and YUL CF-Ray above with the ongoing reports and advise whether a supported recovery or service fix is available.

Account identifiers, installation/enrollment identifiers, local username, device name, tokens and credentials have been omitted.

Start with the Remote Control transport logs in ~/.codex/logs_2.sqlite and the remote control WebSocket endpoint shown in the report. Correlate the timestamp and Cloudflare YUL CF-Ray with reports #44326, #44358, #44384, #44366, and #44313. Done means identifying a supported recovery or service fix so Allow connections succeeds and the host remains available for pairing.