Codex CLI installs a persistent, self-updating background daemon by default

CLI: make daemon_auto_start opt-in — a persistent, self-updating background daemon shouldn't be the default #48195 Description What variant of Codex are you using? CLI — 0.157.0, installed via npm install -g @openai/codex, Linux (WSL2) What feature would you like to see? Please make daemon_auto_start opt-in (default false) for the CLI, or at least ask once before turning it on. Since 0.157.0, just opening an interactive codex session: Starts a persistent background daemon (codex app-server --managed-daemon). It runs in its own session with no TTY and keeps running after every Codex window is closed (reparented to PID 1) until codex app-server daemon stop or a reboot. Copies the whole platform package (~374 MB: codex, codex-code-mode-host, bundled bwrap/zsh/rg) into ~/.codex/packages/app-server-daemon/releases/ / — byte-identical to what npm had just installed — and runs the daemon from that copy. From then on the backend's version is decoupled from the CLI version I installed with my package manager. Starts a detached updater (codex app-server daemon pid-update-loop) that checks for updates 5 minutes after start and then hourly, downloads new releases and restarts the backend (which can kill active turns, see app-server daemon: auto-update force-kills active turns after a 60s drain budget, and cannot be disabled #40969). Pins the environment of whichever session happened to start it. I launch Codex through a wrapper that sets HTTPS_PROXY per invocation; the daemon keeps the first session's proxy variables and its outbound connections go through that proxy, whatever later sessions are launched with. Hooks in --remote mode receive the daemon's cwd, not the session's #42457 and Hooks spawned by the app-server daemon cannot identify the client terminal, breaking terminal-targeting hooks #37537 (daemon cwd / terminal instead of the session's) look like the same root cause. For a CLI, the least surprising default is that the backend lives and dies with the window, runs the binary I installed, and doesn't update itself in the background. A shared, self-updating daemon makes sense for Remote Control / the desktop app, so it would be fine to enable it there, or when the user explicitly runs codex app-server daemon start / bootstrap. If it stays on by default, please at least: exit an auto-started daemon when its last client disconnects; not copy/self-update when the CLI was installed by a package manager (npm/brew/pacman) — run the installed binary instead ( Support externally managed app-server daemon executables #41188, npm update leaves app-server on old version, but daemon update/restart refuse recovery #46468, Codex 0.157.0 no longer starts with the Arch Linux package unless --no-daemon is used #48050). Additional information Bug found while turning it off: codex app-server daemon stop stops the app-server but leaves the pid-update-loop updater running (still alive 70 s later, had to kill it manually). Workaround I'm using: codex features disable daemon_auto_start codex app-server daemon stop pkill -f 'app-server daemon pid-update-loop' # not stopped by `daemon stop` rm -rf ~/.codex/packages/app-server-daemon With the flag off, a new TUI session no longer spawns a daemon. Related: #40969, #41188, #46468, #48050, #42457, #37537 Activity github-actions added enhancementNew feature or requestNew feature or request CLIIssues related to the Codex CLIIssues related to the Codex CLI app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces on Sep 25, 2026 megahall commented on Sep 25, 2026 megahall on Sep 25, 2026 More actions @Yihua-Liu-1997 thanks for reporting this, I hit it myself... stuff should not be creating mystery servers and processes all of a sudden on small version number bumps without giving people a heads-up... 👍React with 👍5Reacted by tagor, Flaviu Tamas, Felipe Lopes, Josh Triplett and BigBoyDevBox megahall commented on Sep 25, 2026 @Yihua-Liu-1997 thanks for reporting this, I hit it myself... stuff should not be creating mystery servers and processes all of a sudden on small version number bumps without giving people a heads-up... kr8vka0z commented on Sep 25, 2026 kr8vka0z on Sep 25, 2026 More actions agreed. the CLI is unusable until this is fixed. 👍React with 👍7Reacted by tagor, Steven Dale, Felipe Lopes, krrr, Shaun Pedicini, Christian Hahn and BigBoyDevBox kr8vka0z commented on Sep 25, 2026 agreed. the CLI is unusable until this is fixed. tagorr commented on Sep 25, 2026 tagorr on Sep 25, 2026 More actions I can confirm this on Windows 10 LTSC with Codex CLI 0.157.0 Setting daemon_auto_start = false in config.toml resolves the issue Two improvements would help: Automatically fall back to local mode when daemon startup is blocked by elevation, instead of requiring --no-daemon. Make daemon auto-start opt-in rather than the default. This would preserve the security restrictions without disrupting the normal CLI workflow. 👍React with 👍1Reacted by BigBoyDevBox tagorr commented on Sep 25, 2026 I can confirm this on Windows 10 LTSC with Codex CLI 0.157.0 Setting daemon_auto_start = false in config.toml resolves the issue Two improvements would help: Automatically fall back to local mode when daemon startup is blocked by elevation, instead of requiring --no-daemon. Make daemon auto-start opt-in rather than the default. This would preserve the security restrictions without disrupting the normal CLI workflow. Yihua-Liu-1997 commented on Sep 26, 2026 Yihua-Liu-1997 on Sep 26, 2026 Author More actions @tagorr Indeed — both 1 and 2 would work~ ❤️React with ❤️1Reacted by tagor Yihua-Liu-1997 commented on Sep 26, 2026 @tagorr Indeed — both 1 and 2 would work~ breakds added a commit that references this issue on Sep 28, 2026 codex: disable daemon auto-start by default ... b51c036 codex: disable daemon auto-start by default felipeelopes commented on Sep 29, 2026 felipeelopes on Sep 29, 2026 More actions The Codex CLI is unusable due to this bug on Windows. felipeelopes commented on Sep 29, 2026 The Codex CLI is unusable due to this bug on Windows. zdd commented on Sep 30, 2026 zdd on Sep 30, 2026 More actions This is terrible. I can't input anything on the CLI at all. You should fix this problem as soon as possible and give us 100 banked reset! zdd commented on Sep 30, 2026 This is terrible. I can't input anything on the CLI at all. You should fix this problem as soon as possible and give us 100 banked reset! aetherxeg-source commented on Oct 3, 2026 aetherxeg-source on Oct 3, 2026 – with ChatGPT Codex Connector More actions There is a useful provenance boundary behind this request: installed CLI identity != daemon execution identity Once the CLI copies itself into a managed release directory and a background updater can replace that copy, the process that services a later turn is no longer necessarily the artifact the user explicitly installed or invoked. I would make the daemon expose a small execution receipt for each client attachment containing at least: client_cli_version + daemon_binary_digest + daemon_generation + updater_state + inherited_environment_generation Then a client can distinguish: same installed artifact, same daemon generation; same CLI but different daemon generation; daemon binary changed independently of the package-manager state; daemon inherited environment from an earlier session. A strong regression would start the daemon under environment A, attach from environment B, update the installed CLI, and verify that the client can see exactly which daemon generation/binary/environment is authoritative for the turn rather than inferring it from the foreground CLI version. Related runtime behavioral-integrity work: https://github.com/AETHERXGLOBAL/execsurface aetherxeg-source commented on Oct 3, 2026 There is a useful provenance boundary behind this request: installed CLI identity != daemon execution identity Once the CLI copies itself into a managed release directory and a background updater can replace that copy, the process that services a later turn is no longer necessarily the artifact the user explicitly installed or invoked. I would make the daemon expose a small execution receipt for each client attachment containing at least: client_cli_version + daemon_binary_digest + daemon_generation + updater_state + inherited_environment_generation Then a client can distinguish: same installed artifact, same daemon generation; same CLI but different daemon generation; daemon binary changed independently of the package-manager state; daemon inherited environment from an earlier session. A strong regression would start the daemon under environment A, attach from environment B, update the installed CLI, and verify that the client can see exactly which daemon generation/binary/environment is authoritative for the turn rather than inferring it from the foreground CLI version. Related runtime behavioral-integrity work: https://github.com/AETHERXGLOBAL/execsurface difro added a commit that references this issue on Oct 7, 2026 Update codex to 0.160.1 with a sandbox patch for nix-user-chroot ... cff8b11 Update codex to 0.160.1 with a sandbox patch for nix-user-chroot danielscoffee added a commit that references this issue on Oct 10, 2026 feat(codex): package Codex CLI from official release binaries ... 4f00eb3 feat(codex): package Codex CLI from official release binaries Metadata Metadata Assignees Labels Type Projects Milestone Relationships Development Issue actions Open in GitHub Copilot app