Remote-control daemon remains on old version after CLI update and becomes unrecoverable
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:
- Stop the old app-server process.
- Start the new version.
- Recreate the control socket.
- 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.
- Start Remote Control with Codex CLI
0.144.6:
```bash
codex --version
# codex-cli 0.144.6
codex remote-control start --json
- Confirm the daemon is running:
pgrep -af "codex.*app-server"
- Update Codex CLI to 0.145.0 using the normal update mechanism without manually restarting Remote Control.
- Confirm that the CLI is updated:
codex --version
# codex-cli 0.145.0
- Wait until the host disconnects from Remote, or try to start Remote Control again:
codex remote-control start --json
- 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
- Trying to stop it also fails:
codex remote-control stop --json
Error: timed out waiting for pid-managed app server to stop
- 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_
1 Comment
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_HOMEprofile after the Unix-WebSocket client began receivingConnection reset without closing handshake:app-server --remote-controlbecame aZ/defunct child of its liveapp-server daemon pid-update-loopparent.codex app-server daemon restartandstophung/timed out;startfailed readiness withConnection refused, so the managed path could not self-repair.Recovery required stopping the exact stale pid-update-loop, moving (not deleting) that one profile's
app-server-daemon/andapp-server-control/state aside, then runningCODEX_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 starttimer may make this lifecycle race more likely, but it is not required for the failed recovery state above.