Remote-control device list disappears on macOS even while Linux app-server is connected

Summary

After updating Codex Desktop on macOS, Settings > Connections > Control other devices briefly showed several remote-control devices, then the list was cleared and now shows No devices added yet. Refreshing the list does not bring the devices back.

At the same time, the Linux remote-control app-server is healthy and reports connected, so this looks like a macOS controller / backend device-list or enrollment synchronization issue rather than a Linux daemon failure.

Environment

Controller machine:

• macOS Codex Desktop
• bundled CLI: codex-cli 0.142.4
• UI path: Settings > Connections > Control other devices

Remote Linux machine:

• hostname: CM2LA_MASTER
• CLI/app-server: 0.142.4
• remote-control environment id observed: env_e_6a2c15...39c (redacted)
• launched with: codex remote-control start --json

Also affected / previously visible:

• Windows devices previously appeared in the same macOS device list, but disappeared as well.

Expected behavior

If the Linux machine reports remote-control connected and codex doctor --summary is clean, the macOS Control other devices list should show the Linux device, or at least provide a working re-add/reauthorization path for the Linux CLI remote-control device.

Actual behavior

1. Immediately after updating Codex Desktop, the macOS device list briefly showed stale/offline devices, including the Linux host and Windows hosts.
2. After a short delay, the list became empty and showed No devices added yet.
3. Clicking refresh continues to return an empty list.
4. Clicking Add opens a PIN flow intended for another Mac/PC Codex Desktop app. The Linux CLI codex remote-control command does not appear to expose a matching add, pair, or pin subcommand.

Linux state

The Linux side was first in a bad app-server state after the update, then was repaired. After repair, it consistently reported connected:

{
  "mode": "daemon",
  "status": "connected",
  "serverName": "CM2LA_MASTER",
  "environmentId": "env_e_6a2c15...39c",
  "timedOut": false,
  "daemon": {
    "status": "alreadyRunning",
    "backend": "pid",
    "managedCodexPath": "/home/<user>/.codex/packages/standalone/current/codex",
    "managedCodexVersion": "0.142.4",
    "socketPath": "/home/<user>/.codex/app-server-control/app-server-control.sock",
    "cliVersion": "0.142.4",
    "appServerVersion": "0.142.4"
  }
}

codex doctor --summary on Linux also passed:

Connectivity
  ✓ websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
  ✓ reachability active provider endpoints are reachable over HTTP

Background Server
  ✓ app-server   running (persistent mode)

18 ok · 0 warn · 0 fail

The Linux app-server processes were running:

/home/<user>/.codex/packages/standalone/current/codex app-server --remote-control --listen unix://
/home/<user>/.codex/packages/standalone/current/codex app-server daemon pid-update-loop

macOS local state

The macOS global state still had the current Linux remote-control env id as added/allowed/autoconnect:

{
  "added-remote-control-env-ids": ["env_e_6a2c15...39c"],
  "host-id-remote-control-allowed": [
    "remote-control:env_e_6a2c15...39c"
  ],
  "remote-connection-auto-connect-by-host-id": {
    "remote-control:env_e_6a2c15...39c": true
  }
}

However, the visible UI still showed No devices added yet.

macOS logs

On app startup / first refresh, macOS briefly created remote-control entries:

2026-06-30T00:35:28.283Z info [remote-connections/window-context] refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=4 previousConnectionCount=0

Immediately afterwards, status reads for those remote-control host IDs failed with Connection for host ID ... not found:

2026-06-30T00:35:28.402Z error [electron-message-handler] Request failed ... method=remoteControl/status/read ... error={"code":-32000,"message":"Connection for host ID remote-control:env_e_6a1a...00d not found"}
2026-06-30T00:35:28.402Z error [electron-message-handler] Request failed ... method=remoteControl/status/read ... error={"code":-32000,"message":"Connection for host ID remote-control:env_e_6a3e...c98 not found"}
2026-06-30T00:35:28.404Z error [electron-message-handler] Request failed ... method=remoteControl/status/read ... error={"code":-32000,"message":"Connection for host ID remote-control:env_e_6a2c...877 not found"}
2026-06-30T00:35:28.404Z error [electron-message-handler] Request failed ... method=remoteControl/status/read ... error={"code":-32000,"message":"Connection for host ID remote-control:env_e_6a1c...a98 not found"}

A later refresh pruned those remote-control managers and reduced the list to zero:

2026-06-30T00:37:46.594Z info [remote-connections/window-context] refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=0 previousConnectionCount=4
2026-06-30T00:37:46.599Z info [electron-message-handler] remote_connections.manager_state_set hostId=remote-control:env_e_6a1a...00d ... source=registry_delete_manager
2026-06-30T00:37:46.602Z info [electron-message-handler] remote_connections.manager_state_set hostId=remote-control:env_e_6a3e...c98 ... source=registry_delete_manager
2026-06-30T00:37:46.604Z info [electron-message-handler] remote_connections.manager_state_set hostId=remote-control:env_e_6a2c...877 ... source=registry_delete_manager
2026-06-30T00:37:46.606Z info [electron-message-handler] remote_connections.manager_state_set hostId=remote-control:env_e_6a1c...a98 ... source=registry_delete_manager

After the Linux side was repaired and confirmed connected, repeated macOS refreshes still returned zero remote-control devices:

2026-06-30T00:48:39.450Z info [AppServerConnection] response_routed ... method=remoteControl/client/list ... errorCode=null
2026-06-30T00:48:43.021Z info [remote-connections/window-context] refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=0 previousConnectionCount=0

2026-06-30T00:49:40.819Z info [remote-connections/window-context] refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=0 previousConnectionCount=0
2026-06-30T00:50:15.392Z info [remote-connections/window-context] refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=0 previousConnectionCount=0

CLI help / re-add path issue

On macOS, the Add a device dialog displays an 8-digit PIN flow and says to open Codex on the computer to control, then go to Settings > Connections > Control this Mac or PC > Add.

For Linux CLI remote-control, codex remote-control --help only shows:

Commands:
  start  Start the app-server daemon with remote control enabled
  stop   Stop the app-server daemon
  help   Print this message or the help of the given subcommand(s)

codex remote-control start --help also does not expose a PIN/pairing/add command. So once the macOS controller list gets into this empty/stale state, there does not seem to be an obvious way to re-add a headless Linux CLI remote-control device through the PIN flow.

Suspected problem

This looks like a mismatch between:

• Linux remote-control daemon state: connected and healthy
• macOS local state: still remembers the current Linux env id as added/allowed/autoconnect
• macOS/backend remoteControl/client/list: returns no current controllable devices after pruning stale managers
• UI Add flow: exposes a Mac/PC PIN flow but no apparent Linux CLI pairing path

It may be related to controller client enrollment rotation after the update/reset. The current macOS controller enrollment appears to be new, while previously authorized remote-control devices may still be associated with stale controller/client records.

Impact

Remote-control becomes unusable from macOS even though the remote Linux app-server is connected, current, and healthy. Refreshing the macOS UI does not recover it, and the available Add-device flow does not seem applicable to Linux CLI remote-control devices.

Requested improvements

1. If remoteControl/client/list returns zero devices while local state has allowed remote-control env ids, surface a repair/re-add state instead of silently showing an empty list.
2. Provide a documented Linux CLI pairing/re-authorization command for the 8-digit PIN flow, or route Linux users to the correct SSH/remote-control re-add path.
3. Avoid creating stale remote-control managers that immediately fail with Connection for host ID ... not found, or expose a clearer diagnostic when this backend/client mismatch happens.
4. Add a codex remote-control status --json command that reports the same reliable state as codex remote-control start --json without side effects.