Stale app-server survives CLI update and causes 0.147.0 TUI to use pre-0.147 `spawn_agent` model filtering

What version of Codex CLI is running?

codex-cli 0.147.0

Platform

Ubuntu 24.04.4 LTS, Linux x86_64.

Codex installation:

running standalone on linux-x86_64

current executable:
/home/keyhr/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin/codex

version:
0.147.0

The SHA256 of the installed binary exactly matches the rust-v0.147.0 GitHub release binary:

cb0a15567e9a60a5820d54b0f6ae86d504dc3805c1eab21a47f70e3eb7b73a40  installed codex
cb0a15567e9a60a5820d54b0f6ae86d504dc3805c1eab21a47f70e3eb7b73a40  rust-v0.147.0 release binary

What issue are you seeing?

After updating Codex CLI from 0.146.0 to 0.147.0, a normal TUI session still behaves as if it is using the pre-0.147 multi-agent model filtering.

Specifically, from a gpt-5.6-sol parent, spawning gpt-5.6-luna fails:

Unknown model gpt-5.6-luna for spawn_agent.
Available models: gpt-5.6-sol, gpt-5.6-terra

However, starting the same 0.147.0 binary with:

codex --disable tui_app_server -m gpt-5.6-sol

makes the exact same Luna spawn succeed:

Started `/root/luna_spawn_check`
...
LUNA_SPAWN_OK

This appears to be caused by a stale 0.146.0 app-server surviving the CLI update and being reused by the normal TUI path.

Process inspection shows:

PID=12089
codex -c features.code_mode_host=true app-server --listen unix://
/home/keyhr/.codex/packages/standalone/releases/0.146.0-x86_64-unknown-linux-musl/bin/codex

while the currently installed CLI is 0.147.0.

There is also a 0.147.0 app-server proxy process:

codex app-server proxy
/home/keyhr/.codex/packages/standalone/releases/0.147.0-x86_64-unknown-linux-musl/bin/codex

So the system can end up with a 0.147.0 frontend/proxy while a 0.146.0 app-server remains alive.

Why this is particularly visible in 0.147.0

rust-v0.147.0 includes #36892, "Support leaf models in multi-agent v2".

Before that change, a V2 parent such as gpt-5.6-sol rejected the V1/leaf gpt-5.6-luna model. After #36892, Luna should be accepted as a leaf worker.

The effective model catalog on the affected machine is correct:

gpt-5.6-sol     list    v2    true
gpt-5.6-terra   list    v2    true
gpt-5.6-luna    list    v1    true

The bundled model catalog reports the same values.

So this is not a stale model catalog.

The stale app-server makes a 0.147.0 CLI exhibit exactly the old behavior:

Available models: gpt-5.6-sol, gpt-5.6-terra

Reproduction

1. Have Codex 0.146.0 installed and an app-server running.

1. Upgrade Codex to 0.147.0 without manually terminating the existing app-server.

1. Verify the shell CLI is updated:

codex --version
# codex-cli 0.147.0

1. Start a normal Sol session:

codex -m gpt-5.6-sol

1. Call:

spawn_agent(
  model="gpt-5.6-luna",
  fork_turns="none",
  reasoning_effort="low",
  message="Return exactly LUNA_SPAWN_OK"
)

1. Observe:

Unknown model gpt-5.6-luna for spawn_agent.
Available models: gpt-5.6-sol, gpt-5.6-terra

1. Inspect running processes:

for pid in $(pgrep -f 'codex.*app-server'); do
  echo "PID=$pid"
  tr '\0' ' ' < /proc/$pid/cmdline
  echo
  readlink -f /proc/$pid/exe
done

1. Observe that an app-server from the old 0.146.0 installation is still running.

1. Start the same installed 0.147.0 binary while bypassing the app-server-backed TUI:

codex --disable tui_app_server -m gpt-5.6-sol

1. Repeat exactly the same spawn_agent call.

1. It succeeds:

LUNA_SPAWN_OK

Additional A/B verification

On macOS a Homebrew-installed Codex 0.147.0 successfully spawns Luna from a Sol parent.

The parent session log contains:

{
  "name": "spawn_agent",
  "arguments": {
    "model": "gpt-5.6-luna",
    "reasoning_effort": "low"
  }
}

and the resulting child session confirms:

{
  "model": "gpt-5.6-luna",
  "effort": "low"
}

So this is not a silent fallback to Sol.

On the affected Linux machine, a local source build of rust-v0.147.0 also fails through the normal TUI path, but the official 0.147.0 binary succeeds when tui_app_server is disabled. This further points to app-server reuse/version skew rather than the 0.147.0 executable itself.

Feature state

Both working and failing environments report:

multi_agent       stable  true
multi_agent_v2    stable  false

so the difference is not explained by that feature flag.

Expected behavior

When the active CLI is upgraded, the normal TUI should not silently execute turns through an incompatible older app-server.

At minimum, Codex should detect:

CLI version != app-server version

and either:

1. restart/replace the stale app-server automatically,
2. refuse to reuse it and start a matching app-server, or
3. show a clear warning that the active session is running against a different app-server version.

A user seeing:

OpenAI Codex (v0.147.0)

should not unknowingly get 0.146.0 backend behavior.

Workaround

This immediately avoids the problem:

codex --disable tui_app_server

Manually terminating the stale 0.146.0 app-server and allowing a current one to start should also resolve the version skew.

Related issues / changes

• #34721 — old app-server/remote-control daemon survives a CLI update
• #24034 — active CLI and app-server can resolve to different versions
• #36892 — 0.147.0 adds leaf-model support for Multi-Agent V2

This may share the same root cause as #34721 / #24034, but this report demonstrates a concrete functional regression in a normal TUI session: a stale app-server causes a feature added in the currently displayed CLI version to remain unavailable.

Unknown model gpt-5.6-luna.
Available models: gpt-5.6-sol and gpt-5.6-terra.