Long-lived app-server keeps stale paginated metadata behavior after Codex upgrade

Summary

A long-lived Codex App Server can continue serving an older implementation after the local @openai/codex package is upgraded. New paginated threads then fail thread/name/set even though the newly installed Codex version supports the same operation.

Reproduction

Using the same local Codex home and cwd:

1. Start codex-cli 0.145.0-alpha.19 with codex app-server --stdio.
2. Initialize with capabilities.experimentalApi=true.
3. Call thread/start with historyMode: "paginated".
4. Call thread/name/set for the returned non-ephemeral thread.

Observed on 0.145.0-alpha.19:

thread/name/set -> -32601
thread metadata update is not supported by this store: paginated_threads

The same sequence on a fresh codex-cli 0.148.0 App Server succeeds, and thread/read returns the new name for the new paginated thread. A fresh codex-cli 0.144.6 server defaults to historyMode: legacy, where naming also succeeds.

Real-world impact

On a machine with a shared App Server started on 2026-07-23 using the older binary, upgrading the npm package to 0.148.0 did not replace the running server. The process remained alive with its executable shown as (deleted), while new TUI clients continued connecting to its Unix socket. External automatic-title integrations therefore saw repeated failures for newly created paginated sessions.

Expected behavior

After a Codex upgrade, a managed/long-lived App Server should either:

• restart or replace the old server; or
• expose a protocol/version/capability mismatch and refuse the connection with an actionable message.

At minimum, thread/name/set should report that the connected server is stale and identify the server capability/version, rather than returning a store-level error that looks like a permanent paginated-thread limitation.

Evidence

• Client package before/after: 0.145.0-alpha.19 -> 0.148.0
• Old server result: paginated thread/name/set rejected
• Fresh 0.148.0 server result: paginated thread/name/set accepted and verified by thread/read
• Existing shared server start time: 2026-07-23; executable was (deleted) after package replacement
• No credentials, tokens, or private endpoints included

{
  "captured_at": "2026-08-19T07:55:00Z",
  "repository": "openai/codex",
  "incident_head": "0e57385fc2ec4452258b7f2cf9929c95f0d7b847",
  "branch": "main",
  "dirty": true,
  "root_cause_status": "candidate",
  "builder_loop_runtime": {
    "builder_loop_version": "0.1.0",
    "adapter": "codex",
    "adapter_commit": "8140fed742f06babaf41e17703f712454e5ec445",
    "adapter_dirty": false,
    "capture_status": "captured"
  }
}

Start by reproducing the sequence through codex app-server --stdio: initialize experimental APIs, create a paginated thread, then call thread/name/set and thread/read. Trace App Server startup and the thread/name/set handling to determine how a long-lived process exposes its version or capabilities. Done means an upgraded client either connects to a replacement server or receives an actionable stale-server mismatch instead of the store-level error.