# Codex 0.162.1 Still Auto-Starts a Daemon. It Keeps the First Environment. > The primary is Codex CLI 0.162.1, the version npm still marks latest. daemon_auto_start on that tag is stable and on by default, and main still matches. An eligible interactive session starts a managed app-server, and later clients share the environment from when that process started. Remote control defaults off. There is no CVE. The opt-in request dates to 25 September. Source: https://hackerlogs.com/blog/codex-daemon-first-env Published: 2026-10-12 ## Key takeaways - npm latest @openai/codex is 0.162.1, uploaded 9 October at 19:50 UTC. On tag rust-v0.162.1, daemon_auto_start is stable and default_enabled is true. main at 22:44 UTC on 12 October still matches. - The default landed in rust-v0.157.0, published 25 September at 02:31 UTC. The release note is one sentence about automatic background-server startup. - The daemon README on 0.162.1 says shared clients keep the environment from daemon start. A new terminal does not clear it. Per-client isolation is not provided. - A fresh start installs a managed package without the replace-path confirmation, then ensures an updater. The first wait is five minutes, then 60. Only a stable standalone release gets that loop. - daemon stop stops the app-server. It does not stop the updater. The feature flag is not what the launch probe checks, so a live socket is reused while the process remains. - remote_control_enabled defaults to false. Auto-start is not a remote listener. Issue 48195 is an open enhancement, not a CVE. npm's latest `@openai/codex` is `0.162.1`, uploaded 9 October 2026 at 19:50 UTC. On tag `rust-v0.162.1` the feature `daemon_auto_start` is stable and `default_enabled` is true. Commit `92caad782887` on `main`, 22:44 UTC on 12 October, still has that default. An eligible interactive session starts the managed app-server. The [daemon README](https://github.com/openai/codex/blob/rust-v0.162.1/codex-rs/app-server-daemon/README.md) on that tag says later clients keep the environment from when the daemon started. [Hacker News](https://news.ycombinator.com/item?id=50060694) led with that default tonight. US X trends at 22:06 UTC were politics, a celebrity death, football, and the Muse Wonder launch. Trade press was a bring-your-own-agent essay, a SonicWall appliance flaw, and a Claude-assisted intrusion set. None of those is this control. The control is the flag that is still on. Medium because the failure is a shared process environment and a self-updating managed copy, not a CVE and not a remote listener. `remote_control_enabled` defaults to false. Three panels for the Codex managed daemon: the first shell's environment kept for later clients, version 0.162.1 still defaulting auto-start on, and the stop path that leaves the updater running. ## The flag is still the default. `rust-v0.157.0` was published 25 September at 02:31 UTC. npm `0.157.0` followed at 02:35 UTC. The release note's sentence is: enabled automatic background-server startup for eligible interactive sessions, with recovery choices when server settings are incompatible. [Issue 48195](https://github.com/openai/codex/issues/48195) opened at 20:04 UTC that day and asks for the flag to be opt-in. It is still open. The labels are enhancement, CLI, and app-server. On `rust-v0.162.1`, commit `092d3acd`, the TUI starts the daemon when `daemon_auto_start` is enabled, the command is not `--no-daemon`, the session is not the agents overview, and the target is not a remote workspace. The call is `start_with_features`. If a server is already absent, `start` runs `prepare_install` and then launches the managed binary. The missing-package path does not use the confirmation callback. That callback is the replace path. The first auto-start logs that it is installing a daemon from the CLI version and copies a complete package under `packages/app-server-daemon`. A CLI tree with no package manifest fails that prepare step. The error text tells the operator to install a packaged CLI or rerun with `--no-daemon`. That is the distro-package break, not a separate vulnerability. > `DaemonSettings` on this tag defaults `remote_control_enabled` to false. Stored settings default the same field to false. Enabling the auto-start feature does not flip it. Remote control is an explicit command. A daemon that is local and shared is still a local process with the first session's environment. ## The package clock and the impact clock. The package clock is the version npm calls latest, and the source on that tag. `0.162.1` is that version. The GitHub release was published 9 October at 19:44 UTC. The updater constants in the same tag are `INITIAL_UPDATE_DELAY` of five minutes and `DEFAULT_UPDATE_INTERVAL_MINUTES` of 60. `default_auto_update_enabled` returns true. After the app-server starts, `ensure_managed_updater` runs. It starts the loop only when auto-update is on and the managed package is a stable standalone release: a three-part numeric version directory under the daemon releases folder. An install that fails that check does not get the hourly loop. A stable standalone layout does. `stop` stops the app-server backend and waits the shutdown grace, default 60 seconds. It does not call the updater's stop. The updater is a second pid. Turning auto-update off is what makes a later ensure step stop that loop. `stop` alone leaves it. The impact clock is every client that attaches after the daemon is up. The README sentence is the vendor text: shared clients use the environment inherited when the daemon started, and opening a new terminal or clearing variables there does not clear the running daemon's environment. Per-client isolation is not provided. A comment on issue 48195 at 22:43 UTC on 12 October reports a later session seeing the first directory's token variable. That is a report on an open issue. It matches the README. It is not a capture from this desk. > Disabling `daemon_auto_start` stops a future session from calling `start_with_features`. It does not detach a socket that is already listening. The launch probe reuses that socket when the exclusion list is empty, and the feature flag is not on that list. `--no-daemon` is on the list. ## What a later session inherits. The daemon process is the one that holds the environment. A second terminal, a second directory, and a cleared variable in that new shell do not rebuild it. Provider tokens, proxy variables, and anything else that was set when the first eligible session started are the environment the shared server keeps until that process is replaced. The managed copy is a second split. `prepare_install` puts a complete CLI package under the daemon package root, and the server runs from that copy. The binary you invoked and the binary that serves the next turn are not required to be the same file. On a stable standalone release the updater can replace that copy after five minutes and then on the hourly interval. `shutdownGraceSeconds` defaults to 60. A restart can interrupt a turn that is still running. The README says a stopped daemon stays stopped across an explicit update. Do not read that as `stop` killing the updater. Those are different processes. There is no fixed version to upgrade to. `0.162.1` is the latest npm published, and `main` tonight has the same default. Waiting for a newer tag does nothing until the release note says the default flipped. ## What to change before the next launch. Turn `daemon_auto_start` off if this machine should not keep a background server, and use `--no-daemon` on the session you are about to open. Then stop the app-server that is already running. After that, confirm the updater process is gone. `daemon stop` does not stop it. If this host should not take a later stable release on its own, set the daemon updater's auto-update preference off before the next fresh start, because a successful start calls `ensure_managed_updater` and will bring the loop back when the package is a stable standalone release. If the shell that started the current daemon held a long-lived token, rotate that token after the process is gone. The README already says the new terminal will not clear it. Do not treat a quiet session as evidence the token stayed unused. Leave remote control off unless you meant to enable it. Auto-start did not turn it on. The crate's own header still calls the lifecycle experimental. The flag that starts it is marked stable. ## Sources - [CLI: make daemon_auto_start opt-in](https://github.com/openai/codex/issues/48195) (2026-09-25) - [Codex rust-v0.162.1](https://github.com/openai/codex/releases/tag/rust-v0.162.1) (2026-10-09) - [Codex rust-v0.157.0](https://github.com/openai/codex/releases/tag/rust-v0.157.0) (2026-09-25) - [app-server-daemon README at rust-v0.162.1](https://github.com/openai/codex/blob/rust-v0.162.1/codex-rs/app-server-daemon/README.md) (2026-10-09) - [@openai/codex on npm](https://www.npmjs.com/package/@openai/codex) (2026-10-09) - [Codex CLI installs a persistent, self-updating background daemon by default](https://news.ycombinator.com/item?id=50060694) (2026-10-12)