Codex CLI installs a persistent, self-updating background daemon by default
- ID
- 34685
- Status
- summarized
- Published
- 13 Oct 2026, 2:29 AM
- Fetched
- 13 Oct 2026, 5:58 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://github.com/openai/codex/issues/48195
- Source URL
- https://hnrss.org/best
Summary
- Score
- 8.0
- Created
- 13 Oct 2026, 5:59 AM
- Tags
- Audience
- developersvibe_codersai_agent_users
What happened
Issue #48195 on openai/codex asks that `daemon_auto_start` be opt-in, reporting that since Codex CLI 0.157.0 (installed via `npm install -g @openai/codex` on Linux/WSL2) merely opening an interactive session spawns `codex app-server --managed-daemon` with no TTY that survives after all Codex windows close, reparented to PID 1 until `codex app-server daemon stop` or reboot. The daemon copies the ~374 MB platform package (codex, codex-code-mode-host, bundled bwrap/zsh/rg) into `~/.codex/packages/app-server-daemon/releases/<version>/`, so the running backend version decouples from whatever the package manager installed, and it launches a detached `pid-update-loop` that checks for updates 5 minutes after start and then hourly. The reporter also notes the daemon pins the environment of whichever session started it (e.g. per-invocation HTTPS_PROXY), and that hooks in `--remote` mode get the daemon's cwd and terminal rather than the session's (related issues #42457, #37537, #40969).
Why it matters
If you installed Codex CLI 0.157.0 or later via npm, you likely already have a background daemon running and an hourly auto-updater that can force-kill active turns after a 60s drain budget and reportedly cannot be disabled (#40969). Check with `codex app-server daemon stop` and look for the ~374 MB duplicate under `~/.codex/packages/app-server-daemon/`, because `npm uninstall` or a version bump no longer changes what the backend actually runs. Teams that set proxy variables per invocation (common behind corporate proxies) should know the daemon keeps the first session's HTTPS_PROXY for all outbound connections, and anyone relying on terminal-targeting or cwd-sensitive hooks in `--remote` mode should expect the daemon's context, not the session's.
Discussion angle
Should a CLI tool be allowed to install a persistent, self-updating background service by default — and what is your team's rule for tools that leave a daemon running on dev machines after the terminal closes?