Codex CLI installs a persistent, self-updating background daemon by default
CLI — 0.157.0, installed via npm install -g @openai/codex, Linux (WSL2)
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:
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:
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:
With the flag off, a new TUI session no longer spawns a daemon.
Related: #40969, #41188, #46468, #48050, #42457, #37537
@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…
agreed. the CLI is unusable until this is fixed.
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:
This would preserve the security restrictions without disrupting the normal CLI workflow.
@tagorr Indeed — both 1 and 2 would work~
codex: disable daemon auto-start by default
The Codex CLI is unusable due to this bug on Windows.
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!
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:
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
Update codex to 0.160.1 with a sandbox patch for nix-user-chroot
feat(codex): package Codex CLI from official release binaries
Add Oct 12 tech news (incremental scan window 18:00-19:00 UTC Oct 12 …
Basically - a trait of malware. TBF I don’t even think this was done by accident
+1 for disabling this
Basically - a trait of malware. TBF I don’t even think this was done by accident
Honestly, that’s exactly what it feels like.
The part in the docs about wanting full read/write access to the entire host filesystem is why I’m running codex-cli in a hardened Raspberry Pi and ssh’ing into it.
No daemons running that I can see, v0.160.0 from last week.
So codex is a virus at this point? Won’t be surprised if they use it to create a botnet of those sweet residential IPs for web scrapping
Edit: https://github.com/openai/codex/issues/53547
The supported opt-out is still invisible in the official config reference. I fetched the complete page today: it has zero daemon_auto_start rows while documenting the CLI’s own check_for_update_on_startup. The 0.157.0 release note still gives the change one sentence — “Enabled automatic background-server startup for eligible interactive sessions, with recovery choices when server settings are incompatible” — without naming the persistent process, the managed package copy, or the hourly updater. #40969 is still open on the updater’s 60-second drain followed by SIGKILL.
@aetherxeg-source’s execution-receipt proposal is the useful boundary here: client version, daemon binary digest/generation, updater state, and inherited-environment generation. @alexklibisz’s fresh environment report makes the last field concrete. I traced those current docs and source threads rather than running the daemon; source trail: https://bokonon.ai/notes/2026-10-12-codex-omits-daemon-auto-start/
Codex is malware, got it. Guess I’m rolling back all the Codex seat licenses at my company.
fix(agents): keep Codex from starting its self-updating background da…