Codex CLI 0.157.0+ leaves a self-updating background server running after every session closes (`codex app-server --managed-daemon` plus an hourly updater) and keeps the first session's proxy

Context

Source(s): https://github.com/openai/codex/issues/48195 Status: reported working by source, not reproduced by us (workaround only; root fix not confirmed).

Problem

Since 0.157.0, opening an interactive codex session starts a shared background server in its own session with no terminal. It copies the whole platform package (about 374 MB, byte-identical to what npm installed) into ~/.codex/packages/app-server-daemon/releases/<version>/ and runs from that copy, so its version no longer follows the CLI you installed. A detached updater checks for updates 5 minutes after start and then hourly, downloads new releases and restarts the server. The server keeps the environment of whichever session started it: the original poster sets HTTPS_PROXY per run through a wrapper, but the server kept the first session's proxy for all later sessions. A commenter found 1.3 GB of updates downloaded in the background after a few days.

Error (redacted / normalized)

Symptom (no error text): after an interactive `codex` session, the processes `codex app-server --managed-daemon` and `codex app-server daemon pid-update-loop` keep running after every Codex window is closed (reparented to PID 1), until `codex app-server daemon stop` or a reboot.

Applies when

Codex CLI 0.157.0 and later, installed with npm install -g @openai/codex; Linux on WSL2 (original poster); reported September to October 2026.

Confirm it is this problem

1. Close every Codex session, then run ps -ef | grep -E 'app-server (--managed-daemon|daemon pid-update-loop)' | grep -v grep → expect: one or both processes are still listed.
2. ls ~/.codex/packages/app-server-daemon/releases/ → expect: one or more version folders.

Not this when / boundary

On Windows, codex refuses to start with Error: Access is denied. (os error 5) or start the Windows daemon from a non-elevated terminal; that start failure has its own FixLore post (fix/122). You rely on Remote Control or the desktop app, which the original poster said is where a shared server makes sense; turning it off may affect those (our inference). A commenter on 0.160.0 saw no daemon at all, so not every session starts one; the release note says "eligible interactive sessions".

Root cause

The 0.157.0 release note says "Enabled automatic background-server startup for eligible interactive sessions, with recovery choices when server settings are incompatible". The behavior is behind the feature flag daemon_auto_start, which is on by default for the CLI. A commenter said the official config reference had no row for daemon_auto_start on 2026-10-12. The original poster found that codex app-server daemon stop stops the server but leaves the updater running.

Variables

none.

Fix

1. codex features disable daemon_auto_start → expect: the original poster said that with the flag off, a new TUI session no longer starts a daemon. A commenter on Windows 10 LTSC with 0.157.0 said setting daemon_auto_start = false in config.toml resolved their issue, but their issue was the elevated-terminal start failure covered by fix/122; the sources of fix/122 put that line under a [features] section.
2. codex app-server daemon stop → expect: the --managed-daemon process exits.
3. pkill -f 'app-server daemon pid-update-loop' → expect: the updater exits; the original poster found it still alive 70 seconds after daemon stop and had to kill it.
4. Optional: rm -rf ~/.codex/packages/app-server-daemon → expect: the managed copy (about 374 MB) is gone; the original poster does this as part of the workaround.

How to verify

Open a new codex session, exit it, then rerun confirm 1 → expect: neither process is listed.

What did not work

codex app-server daemon stop alone leaves the updater running (original poster).

Rollback

Turn the flag back on (codex features enable daemon_auto_start should be the reverse of step 1, our inference), or remove the daemon_auto_start = false line from config.toml.

Risks

pkill -f kills every process whose command line contains that text; check with pgrep -fl 'app-server daemon pid-update-loop' first (our inference). Do not run the rm -rf in step 4 until you have checked the path; it only removes the managed copy, which Codex recreates if the flag is turned back on (our inference). The updater can restart the server mid-turn; the original poster linked a separate open issue about active turns being killed. Commenters linked third-party write-ups and projects; we have not reviewed them (our inference).

Verified scope

Codex CLI 0.157.0 and later, September to October 2026.

Becomes obsolete when

daemon_auto_start becomes opt-in for the CLI or the server exits with its last client. Open question: whether the flag stays off after the CLI is updated; the issue is still open and nobody reported on that.