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

Immediately after updating Codex Desktop, the macOS device list briefly showed stale/offline devices, including the Linux host and Windows hosts.
After a short delay, the list became empty and showed No devices added yet.
Clicking refresh continues to return an empty list.
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

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.
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.
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.
Add a codex remote-control status --json command that reports the same reliable state as codex remote-control start --json without side effects.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Windows Codex Desktop remote-control QR pairing remains stuck after stale remote hosts are cleaned up #30165

Powered by Codex Action

I reviewed #30165 after the duplicate-detection bot comment. This is related, but I do not think it is the same failure mode.

#30165 is mainly about stale remote hosts plus Windows Desktop QR pairing remaining stuck after cleanup. In this issue, the Linux target itself is already healthy and connected:

codex remote-control start --json -> status: connected
cliVersion/appServerVersion: 0.142.4
codex doctor --summary -> 18 ok · 0 warn · 0 fail

The macOS controller then successfully routes remoteControl/client/list, but the refreshed remote-control list converges to zero devices:

remoteControl/client/list ... errorCode=null
refresh_remote_control_completed ... nextConnectionCount=0 previousConnectionCount=0

This is different from a Windows QR pairing flow getting stuck. The problematic mismatch here is:

Linux CLI remote-control daemon is connected and healthy.
macOS local state still contains the current Linux env as added/allowed/autoconnect.
macOS/backend client list returns no controllable devices.
The visible Add-device flow is a PIN flow for another Codex Desktop app, while Linux CLI exposes only remote-control start and stop, with no apparent pair/add/pin command.

So I am keeping this issue open as a Linux CLI remote-control / macOS controller-list synchronization and reauthorization-path issue, while linking #30165 as related background for stale remote-control state after updates.

I ran into a very similar CLI/headless re-add problem while trying to get ChatGPT mobile paired back to a Codex CLI host. The part that confused me was the same one called out here: the remote app-server can be connected, but the current UI flow expects a QR/manual-code pairing path that the CLI does not really expose.

For my own setup I ended up wrapping the experimental app-server remote-control pairing RPCs into a small helper:

https://github.com/mjzcng/codex-cli-mobile-pairing

It basically does remoteControl/enable + remoteControl/pairing/start with manualCode: true, and the newer version can keep the resulting app-server running in the background:

npx codex-cli-mobile-pairing start
npx codex-cli-mobile-pairing status
npx codex-cli-mobile-pairing restart
npx codex-cli-mobile-pairing stop

This is not a fix for the macOS/backend device-list sync issue itself, but it gave me a usable manual pairing code for a CLI-hosted environment and made it easier to tell whether the missing piece was "no current pairing session" vs. "device list/client sync is broken".

I can reproduce this on a current macOS-to-macOS Remote Control setup, with the same manager-pruning signature after an app update.

Controller environment

ChatGPT/Codex Desktop: 26.825.32147 (build 7303)
macOS: 26.6.2 (25G83)
Remote host: a second Mac on the same ChatGPT account/workspace
No raw identifiers, project names, account data, or unfiltered logs are included below

Observed sequence (UTC, 2026-09-03)

The paired remote Mac was connected and usable until approximately 14:12.
The remote Mac subsequently installed an app update (observed by the user when opening the machine).
Beginning around 14:47, the controller's reconnect attempts failed with HTTP 404 responses.
The controller later required explicit Remote Control authorization again.

Reauthorization completed successfully at 18:06:12, but the enrollment was treated as new:

remote_control_client_enrollment_step_up_validated hasExistingEnrollment=false
remote_control_client_enrollment_finish_response ... scopes=[remote_control_controller_websocket]

Immediately after successful authorization, reconciliation removed the previously saved host:

refresh_remote_control_started previousConnectionCount=1
reconcile_completed nextConnectionCount=0 previousConnectionCount=1
refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=0 previousConnectionCount=1
remote_connections.manager_state_set ... source=registry_delete_manager

Repeated manual refreshes then returned no recovery path:

load_completed savedRemoteConnectionCount=0 totalConnectionCount=0
refresh_completed autoConnectConnectionCount=0 codexManagedConnectionCount=0 discoveredConnectionCount=0 nextConnectionCount=0
refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=0

The remote projects also disappeared from the controller's project list when the host manager was pruned. The user must pair/add the same physical Mac again.

Expected behavior

Installing or relaunching after a desktop update should preserve the logical pairing.
A temporary host restart should show the device as offline/reconnecting, then recover automatically when it returns.
Reauthorizing the controller should not silently delete previously paired hosts.
If an enrollment must rotate, the app should migrate the existing host/project associations or present a one-click repair action.
The Connections UI should surface a clear reason and recovery button instead of requiring the user to infer that the host must be added again.

This broadens the original report from a macOS controller + Linux host to a Mac-to-Mac pairing and suggests the failure is in controller enrollment/device-list reconciliation rather than the remote host platform.

Navigation Menu

Repository navigation

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

Summary

Environment

Expected behavior

Actual behavior

Linux state

macOS local state

macOS logs

CLI help / re-add path issue

Suspected problem

Impact

Requested improvements

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Expected behavior

Actual behavior

Linux state

macOS local state

macOS logs

CLI help / re-add path issue

Suspected problem

Impact

Requested improvements

Activity

github-actions commented on Jun 30, 2026

kimyeongjong commented on Jun 30, 2026

mjzcng commented on Jul 8, 2026

alexwes commented on Sep 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions