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

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/<version>/ — 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

@Yihua-Liu-1997

@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:

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.

@tagorr

@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:

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

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

agree, good move

Navigation Menu

Repository navigation

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

What variant of Codex are you using?

What feature would you like to see?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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?

What feature would you like to see?

Additional information

Activity

megahall commented on Sep 25, 2026

kr8vka0z commented on Sep 25, 2026

tagorr commented on Sep 25, 2026

Yihua-Liu-1997 commented on Sep 26, 2026

felipeelopes commented on Sep 29, 2026

zdd commented on Sep 30, 2026

aetherxeg-source commented on Oct 3, 2026

laurynas-karvelis commented on Oct 12, 2026

skhaz commented on Oct 12, 2026

tagorr commented on Oct 12, 2026

st396gt commented on Oct 12, 2026

Logarithmus commented on Oct 12, 2026

mateolafalce commented on Oct 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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