Codex CLI's Default Daemon Installation Sparks User Concern

CLI: make daemon_auto_start opt-in — a persistent, self-updating background daemon shouldn't be the default

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:

1. 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.
2. 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.
3. 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).
4. 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

megahall commented 2 weeks ago 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 2 weeks ago on Sep 25, 2026

agreed. the CLI is unusable until this is fixed.

tagorr commented 2 weeks ago 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:

1. Automatically fall back to local mode when daemon startup is blocked by elevation, instead of requiring --no-daemon.
2. 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 2 weeks ago on Sep 26, 2026

@tagorr Indeed — both 1 and 2 would work~

felipeelopes commented 2 weeks ago on Sep 29, 2026

The Codex CLI is unusable due to this bug on Windows.

zdd commented 2 weeks ago 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 last week 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

foma-agent commented last week on Oct 3, 2026

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/

shakefu commented 3 hours ago on Oct 13, 2026

Codex is malware, got it. Guess I’m rolling back all the Codex seat licenses at my company.

laurynas-karvelis commented 10 hours ago on Oct 12, 2026

Basically - a trait of malware. TBF I don't even think this was done by accident

skhaz commented 10 hours ago on Oct 12, 2026

+1 for disabling this

tagorr commented 10 hours ago on Oct 12, 2026

Basically - a trait of malware. TBF I don't even think this was done by accident

Honestly, that's exactly what it feels like.

st396gt commented 10 hours ago on Oct 12, 2026

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.

Logarithmus commented 9 hours ago on Oct 12, 2026

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

mateolafalce commented 9 hours ago on Oct 12, 2026

agree, good move

alexklibisz commented 7 hours ago on Oct 12, 2026

Edit: #53547