npm update leaves app-server on old version, but daemon update/restart refuse recovery

npm update leaves app-server on old version, but daemon update/restart refuse recovery

What version of Codex CLI is running?

codex-cli 0.155.0

The still-running background app-server reported 0.154.0.

Component

Codex CLI / app-server daemon / npm updater

Platform

• WSL2: Linux 6.18.33.2-microsoft-standard-WSL2 x86_64
• Ubuntu 26.04 LTS
• Node.js v22.23.1
• npm 10.9.8
• npm package: @openai/codex@0.155.0

What issue are you seeing?

This is the second time an npm update has left the running app-server on the previous Codex version with no supported recovery path.

The CLI, npm package, and native binary on disk were already 0.155.0, but the app-server process had started immediately before the npm update and remained 0.154.0:

{
  "status": "running",
  "managedCodexPath": "/home/sbw/.codex/packages/standalone/current/codex",
  "managedCodexVersion": null,
  "socketPath": "/home/sbw/.codex/app-server-control/app-server-control.sock",
  "cliVersion": "0.155.0",
  "appServerVersion": "0.154.0"
}

At that time there was no standalone installation at the reported managedCodexPath. The visible ~/.local/bin/codex was a wrapper that loaded NVM and executed the npm-installed CLI:

~/.nvm/versions/node/v22.23.1/bin/codex
  -> ../lib/node_modules/@openai/codex/bin/codex.js

The running daemon was from that npm installation:

node ~/.nvm/versions/node/v22.23.1/bin/codex \
  -c features.code_mode_host=true app-server --listen unix://

The process began at 04:05:49, while the npm codex symlink was updated at 04:06. This is consistent with npm replacing the on-disk package while leaving the already-running 0.154.0 daemon alive.

The warning suggested running:

codex app-server daemon update

but that command refused:

{
  "status": "unsupported",
  "managedCodexPath": "/home/sbw/.codex/packages/standalone/current/codex",
  "installedVersion": null,
  "runningVersion": "0.154.0",
  "message": "This command requires a CLI-managed daemon and a stable latest-channel standalone install; update this installation with its owning installer."
}

The obvious fallback also refused:

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

So the CLI detects the mismatch and recommends a command that cannot work for the npm installation, while the restart command also refuses to recover it.

Steps to reproduce

1. Install Codex globally through npm and start the shared app-server daemon from that installation.
2. Keep a client connected to the daemon.
3. Upgrade @openai/codex globally from 0.154.0 to 0.155.0 without first stopping the daemon.
4. Run codex app-server daemon version and observe CLI 0.155.0 with app-server 0.154.0.
5. Run codex app-server daemon update and codex app-server daemon restart.
6. Observe that update reports unsupported and restart reports that the running server is not managed.

Expected behavior

At least one supported recovery path should work:

• npm updates should stop/restart a daemon launched from the package being replaced; or
• the newer CLI should be able to restart a reachable older daemon from the same npm installation; or
• the warning should provide an npm-specific command that actually reconciles the running daemon; or
• doctor / daemon version should explain that the process predates the package update and offer a safe takeover flow.

It is also misleading for an npm-managed invocation to report a nonexistent standalone path as managedCodexPath.

Actual recovery required

Normal TERM did not make the old daemon exit within 10 seconds while clients were connected. Recovery required:

1. Install the official standalone 0.155.0 distribution.
2. Replace the visible CLI path with the standalone symlink.
3. Force-kill the old npm daemon process group.
4. Remove the unowned control socket.
5. Start a new managed standalone daemon.

After that, the daemon reported:

{
  "status": "running",
  "managedCodexVersion": "0.155.0",
  "cliVersion": "0.155.0",
  "appServerVersion": "0.155.0"
}

Related issue

Possibly related to #44037 because both end in a reachable but “unmanaged” daemon. However, #44037 attributes lost management to WSL2 clock changes and PID start-time validation. This case was tied to an npm package update leaving the old process alive, with no standalone installation or management metadata present.

Start by reproducing the mismatch with the npm-installed codex app-server daemon version, update, and restart commands described in the issue. Trace how the CLI identifies daemon ownership and handles a package update while the older process remains running. Done means an npm installation has a supported, safe recovery path and reports accurate management state.