Codex daemon bootstrap reports an unmanaged app server

Symptom. codex app-server daemon bootstrap fails with app server is running but is not managed by codex app-server daemon.

Root cause. A directly launched codex app-server --listen unix:// already owns the control socket for this CODEX_HOME, but has no daemon process record. Desktop SSH connections can launch this way. In Codex 0.162.1, bootstrap refuses to adopt that process; daemon stop and restart refuse it too. Management uses a PID file, so the absence of a systemd unit is expected.

Confirm. Inspect the current CLI, server version, and exact process:

1
type -a codex
2
codex app-server daemon version
3
ps -u "$(id -u)" -o pid,ppid,args | rg '[c]odex.*app-server'

An unmanaged server can report status: running while omitting backend and reporting managedCodexVersion: null. Check the process environment to confirm it uses the same CODEX_HOME. Do not confuse the SSH app-server proxy process with the server itself.

Fix. Prepare a complete native CLI package before stopping anything. A stale npm launcher may shadow the managed native binary; bootstrap also needs the complete package to create its daemon install. For example, to retain the observed 0.162.1 version:

1
CODEX_VERSION=rust-v0.162.1 bash ~/dotfiles/install/codex.sh install

Wait for active work to finish and disconnect the desktop’s SSH connection. After checking its identity again, send SIGTERM to the exact unmanaged server PID and wait for it to exit. This disconnects clients; avoid broad pkill commands, deleting the socket, or fabricating a daemon PID file. Then run:

1
codex app-server daemon bootstrap
2
codex app-server daemon version
3
codex app-server daemon start

Expect bootstrapped, then running and alreadyRunning, with backend: pid and the expected managed version. Reconnect the desktop afterward. Plain bootstrap leaves remote control disabled; SSH access does not require enabling it. See the 0.162.1 daemon lifecycle contract.