›_ Codex Issues
Codex Issues / #32983

App update leaves the previous app-server daemon running

Open 💬 2 comments Opened Jul 14, 2026 by galah92
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.144.4

What subscription do you have?

Pro

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Linux 6.17.0-1016-gcp x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Ghostty & tmux

Codex doctor report

What issue are you seeing?

After Codex updated from 0.144.2 to 0.144.4, the persistent app-server daemon remained on 0.144.2. It was not restarted or replaced as part of the update, leaving remote control unavailable.

Running codex remote-control start only exposed the stale daemon state:

~ ❯ codex remote-control start
Starting app-server daemon with remote control enabled...
Error: app server did not become ready on /home/my/.codex/app-server-control/app-server-control.sock

 Daemon used app-server:
 path: /home/my/.codex/packages/standalone/current/codex
 version: 0.144.4

 Managed app-server stderr (/home/my/.codex/app-server-daemon/app-server.stderr.log):
   2026-07-13T06:52:56.322812Z ERROR codex_models_manager::manager: failed to refresh available models: timeout waiting for child process to exit

Caused by:
    0: failed to connect to /home/my/.codex/app-server-control/app-server-control.sock
    1: Connection refused (os error 111)

The running daemon was still:

.../releases/0.144.2-x86_64-unknown-linux-musl/bin/codex app-server daemon pid-update-loop

What steps can reproduce the bug?

  1. Install and run Codex standalone version 0.144.2.
  2. Start remote control so the persistent daemon is running: codex remote-control start
  3. Verify the daemon uses 0.144.2: ps -ef | grep 'app-server daemon pid-update-loop
  4. Leave the daemon running and update Codex normally to 0.144.4.
  5. Confirm codex --version reports 0.144.4.
  6. Check the daemon process again.

Observed: the daemon continues running from the 0.144.2 release directory and remote control becomes unavailable. Running codex remote-control start fails with a connection-refused error on app-server-control.sock.

Expected: the update should restart or replace the persistent daemon so it runs 0.144.4 and remote control remains available.

What is the expected behavior?

When Codex updates, the persistent app-server daemon should survive safely or (ideally) be restarted using the new version.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #31835

Powered by Codex Action

mpknott · 15 days ago

I hit a closely related version-skew failure on two separate Linux Codex environments and wanted to add corroborating evidence.

Observed version skew

Both systems had an up-to-date CLI but an older persistent app-server process:

  • Linux Host A: CLI 0.147.0, app-server 0.142.4
  • Linux Host B: CLI 0.147.0, app-server 0.146.0

In both cases, codex doctor reported the background server as healthy even though the persistent app-server version did not match the CLI version.

On Host A, the stale state surfaced as a GPT-5.6-Sol compatibility error saying the model required a newer Codex version, despite the installed CLI already being 0.147.0. A direct codex exec -m gpt-5.6-sol invocation succeeded, which made the split between the current CLI and the stale persistent app-server especially visible.

A separate Windows Codex environment using the same account could run GPT-5.6-Sol successfully, further indicating that account/model availability was not the underlying problem.

Repair that worked

On each Linux host I stopped the stale app-server process, installed/verified the current standalone 0.147.0 binary, and bootstrapped a new managed app-server daemon with remote control enabled. After that:

  • CLI version: 0.147.0
  • app-server version: 0.147.0
  • remote control: working
  • GPT-5.6-Sol: working

So this appears consistent with the updater leaving an older persistent app-server alive while the foreground CLI advances.

One additional concern: codex doctor did not flag the CLI/app-server version mismatch, so an explicit version-consistency check there would likely make this failure much easier to diagnose.

Possibly related but distinct: #33146 documents stale models_cache.json state hiding GPT-5.6 from the model picker. In my case the stronger evidence was the live app-server version mismatch itself.

I have intentionally omitted machine names, usernames, network details, and private paths from this report.