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

Open 💬 1 comment Opened Jul 22, 2026 by gongqiankun

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:

```text
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

  1. Confirm the daemon is running:

pgrep -af "codex.*app-server"

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

codex --version
# codex-cli 0.145.0

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

codex remote-control start --json

  1. 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

  1. Trying to stop it also fails:

codex remote-control stop --json

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

  1. 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_

View original on GitHub ↗

1 Comment

siteexperts · 6 days ago

Confirmed on Linux with Codex CLI/app-server 0.149.0; this is not limited to an in-place version update.

Observed on a second CODEX_HOME profile after the Unix-WebSocket client began receiving Connection reset without closing handshake:

  • app-server --remote-control became a Z/defunct child of its live app-server daemon pid-update-loop parent.
  • The control socket remained on disk but had no listener.
  • codex app-server daemon restart and stop hung/timed out; start failed readiness with Connection refused, so the managed path could not self-repair.
  • The host had ample free memory, no OOM/segfault/coredump evidence, and no file-descriptor pressure.

Recovery required stopping the exact stale pid-update-loop, moving (not deleting) that one profile's app-server-daemon/ and app-server-control/ state aside, then running CODEX_HOME=<profile> codex app-server daemon bootstrap --remote-control. The new socket listened immediately and a new client remained connected.

Expected hardening: the pid manager should treat a zombie child and an unlistened stale socket as dead, reap/replace them automatically, and bound restart/stop instead of waiting indefinitely. A periodic remote-control start timer may make this lifecycle race more likely, but it is not required for the failed recovery state above.