Remote-control daemon remains on old version after CLI update and becomes unrecoverable

Start with the codex remote-control start --json and stop --json paths and the pid-managed app-server lifecycle, reproducing the update from 0.144.6 to 0.145.0 on Linux. Done means the old daemon is stopped, the new app-server creates ~/.codex/app-server-control/app-server-control.sock, and remote control reconnects without manual termination or re-pairing.

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

0.145.0

What subscription do you have?

yes

What platform is your computer?

linux

What issue are you seeing?

Summary

After updating Codex CLI from 0.144.6 to 0.145.0, the remote-control daemon continued running the old 0.144.6 binary.

The process remained alive but lost its control socket and remote network connection, causing the host to appear offline in the ChatGPT mobile app.

Environment

• OS: Linux
• Previous Codex version: 0.144.6
• Updated Codex version: 0.145.0
• Remote control enabled: true

Actual behavior

The old daemon remained running:

codex 0.144.6 app-server daemon pid-update-loop

The current CLI reported:

codex-cli 0.145.0

Running:

codex remote-control start --json

failed with:

Error: app server did not become ready on
~/.codex/app-server-control/app-server-control.sock

Caused by:
failed to connect to app-server-control.sock
No such file or directory

Running:

codex remote-control stop --json

also failed:

Error: timed out waiting for pid-managed app server to stop

The old parent process was stuck in pid-update-loop, and its app-server child was a zombie (defunct). The daemon had no active network connection.

### Expected behavior

After a CLI update, the managed remote-control daemon should:

1. Stop the old app-server process.
2. Start the new version.
3. Recreate the control socket.
4. Automatically reconnect to the remote-control relay.

### Workaround

I manually terminated the stale old daemon and restarted remote control:

kill -TERM <stale-daemon-pid>
codex remote-control start --json

Afterward, the service recovered successfully:

{
  "status": "connected",
  "cliVersion": "0.145.0",
  "appServerVersion": "0.145.0",
  "remoteControlEnabled": true
}

The existing mobile pairing was not the cause; the failure was resolved without requiring a new pairing.

### What steps can reproduce the bug?

### Reproduction steps

This was observed during an in-place CLI update while Remote Control was already running.

1. Start Remote Control with Codex CLI `0.144.6`:

   ```bash
   codex --version
   # codex-cli 0.144.6

   codex remote-control start --json

2. Confirm the daemon is running:

   pgrep -af "codex.*app-server"

3. Update Codex CLI to 0.145.0 using the normal update mechanism without manually restarting Remote Control.
4. Confirm that the CLI is updated:

   codex --version
   # codex-cli 0.145.0

5. Wait until the host disconnects from Remote, or try to start Remote Control again:

   codex remote-control start --json

6. The command fails with:

   Error: app server did not become ready on
   ~/.codex/app-server-control/app-server-control.sock

   Caused by:
   failed to connect to app-server-control.sock
   No such file or directory

7. Trying to stop it also fails:

   codex remote-control stop --json

   Error: timed out waiting for pid-managed app server to stop

8. Process inspection shows that the old 0.144.6 daemon is still running, while its app-server child is defunct:

   pgrep -af "codex.*app-server"
   ps -o pid,ppid,state,cmd -p <daemon-pid>,<app-server-pid>

   Observed state:

   codex 0.144.6 app-server daemon pid-update-loop
   [codex] <defunct>

The stale daemon has no active remote network connection, so the host appears offline in the ChatGPT mobile app.

### Recovery

The service only recovered after manually terminating the stale daemon:

kill -TERM <stale-daemon-pid>
codex remote-control start --json

It then reported:

{
  "status": "connected",
  "cliVersion": "0.145.0",
  "appServerVersion": "0.145.0",
  "remoteControlEnabled": true
}

### Additional information

- Reproduced/observed once during an actual update.
- Existing mobile pairing remained valid.
- Session ID: Not applicable; this occurs in the background daemon outside a Codex session.
- Token limit usage: Not applicable.
- Context window usage: Not applicable.

### What is the expected behavior?

_No response_

### Additional information

_No response_