Codex Desktop SSH restart disables mobile remote control by restarting app-server without --remote-control

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

• #23317
• #22960

Powered by Codex Action

This feels like a control-plane contract bug more than an SSH bug.

If remote control depends on --remote-control, the restart path should either preserve that flag from the live session config or refuse a restart that would downgrade capabilities. Otherwise the app-server comes back "healthy" but with a different authority boundary than the user actually started with.

A useful fix pattern here is to persist the restart receipt alongside the session: previous flags, new flags, and any capability delta. That makes this kind of regression obvious instead of looking like mobile control randomly died.

The strongest signal here is the mismatch between persisted intent and restarted process shape.

remoteControlEnabled: true says the daemon should be reachable from signed-in devices, but the restart path brings back app-server without --remote-control. That makes the host locally healthy while silently losing the mobile-control capability that the user explicitly enabled.

A useful invariant would be: any UI restart action must either preserve the active capability set or return a visible capability downgrade error before stopping the working daemon. The post-restart process flags should be part of the user-visible connection state, because otherwise the mobile app just sees a host that stopped working for no obvious reason.

Yes, and I would make that capability delta machine-readable rather than only human-visible.\n\nSomething like a restart receipt with:\n\n- previous launch flags\n- new launch flags\n- dropped capabilities\n- reason for the restart\n- whether the restart was allowed to proceed despite the downgrade\n\nThat gives the UI one honest state transition to show: healthy with preserved capabilities versus healthy but degraded. Right now the problem is not just that remote control breaks, it is that the restart path makes the downgrade look like success.

AI generation disclosure: This report was drafted with assistance from ChatGPT based on diagnostics I ran and outputs I provided. I reviewed the technical details before posting.

I believe I'm seeing a current variant of this issue with codex-cli 0.147.0.

Environment

Remote host:

Ubuntu Linux
kernel 6.8.0-124-generic
x86_64
codex-cli 0.147.0

The machine is a headless Linux host accessed by Codex clients over SSH. I also use ChatGPT on Android to access it via Codex Remote Control.

Symptoms

The Android app would remain indefinitely at Pending when attempting to connect to the remote host.

Interestingly:

codex remote-control pair

reported successful pairing.

However:

codex remote-control start --json

failed with:

Error: app server is running but is not managed by codex app-server daemon

Existing app-server

The host had these processes:

codex -c features.code_mode_host=true app-server --listen unix://
codex app-server proxy

The first process belonged to an SSH login session. systemctl status <pid> showed:

session-13919.scope - Session 13919 of User <user>
Active: active (abandoned)

with the Codex process still inside the session cgroup:

systemd
└─ codex -c features.code_mode_host=true app-server ...

The corresponding SSH connection itself had already disconnected.

I suspect this may be intentional behavior used by Codex clients to allow reconnection to an SSH-hosted app-server rather than simply an accidentally orphaned process.

Remote-control logs

The remote-control transport itself initialized without WARN or ERROR entries.

Relevant sequence:

starting app-server remote control websocket task
app-server remote control websocket task started
app-server remote control websocket loop started
starting app-server remote control websocket connection cycle
connecting to app-server remote control websocket
reusing persisted remote control enrollment
remote control websocket environment changed status=Connecting
refreshing remote control server token

It remained in Connecting.

The persisted enrollment was recognized, so I did not clear authentication, enrollment, or Codex state.

Recovery

I terminated the SSH session scope containing:

codex -c features.code_mode_host=true app-server --listen unix://

After removing that app-server, the Android client connected successfully without re-pairing, changing authentication, or resetting the remote-control enrollment.

This gives a fairly clean A/B reproduction:

SSH code-mode app-server running
    -> Android Remote Control remains Pending
    -> `remote-control start` reports app-server is not daemon-managed

SSH code-mode app-server removed
    -> existing Android Remote Control connection succeeds

Possible underlying issue

This looks like an ownership/coexistence problem between the SSH code-mode host and the newer daemon-managed Remote Control path.

In particular, an SSH client can apparently leave/reuse:

codex -c features.code_mode_host=true app-server --listen unix://

while Remote Control expects the active app-server to be managed by codex app-server daemon.

Ideally an SSH-hosted Codex server and Remote Control would either:

1. share the daemon-managed app-server,
2. hand ownership over safely, or
3. allow the existing SSH app-server to enable Remote Control without requiring it to be destroyed.

The current behavior makes Remote Control silently appear broken from the Android side (Pending) even though pairing succeeds, while the actionable ownership error is only visible when running codex remote-control start directly on the host.