Key points
- Version 0.157.0 starts a persistent daemon by default upon launching an interactive session.
- The daemon copies the full platform package to a local directory and updates itself hourly.
- Background updates can force-kill active coding turns after a sixty-second drain period.
OpenAI’s Codex command-line interface version 0.157.0 installs a persistent background daemon by default, a change that has sparked concern among users regarding control and transparency. This service operates independently of the terminal session, updating itself in the background and potentially disrupting active workloads without explicit user consent.
What happened
Users reported on the Hacker News front page that version 0.157.0 of the Codex CLI, installed via npm, changes its default behaviour for session management. According to the discussion, simply opening an interactive session triggers the start of a persistent background daemon known as the app-server. This process runs in its own session without a TTY and remains active even after the user closes every Codex window, reparenting to PID 1 until manually stopped or the system reboots.
The daemon copies the entire platform package, approximately 374 MB in size, into a local directory within the user's home folder. This copy includes the codex binary, code-mode-host, and bundled tools such as bwrap, zsh, and rg. From this point forward, the backend version becomes decoupled from the CLI version originally installed by the package manager, meaning the running service may differ from the installed software.
A detached updater process begins checking for new releases five minutes after startup and then every hour thereafter. According to the issue report, this updater downloads new releases and restarts the backend, which can forcibly terminate active coding turns after a sixty-second drain budget. This auto-update mechanism cannot be disabled, as noted in a linked issue regarding force-kills.
The daemon also pins the environment variables from the session that initially started it. If a user launches Codex through a wrapper that sets specific proxy variables per invocation, the daemon retains those first-session proxy settings. Consequently, outbound connections continue through that specific proxy regardless of how subsequent sessions are launched, potentially breaking expected network configurations.
Why it matters
For security operations teams, the default installation of a self-updating daemon introduces significant visibility and control challenges. The decoupling of the backend from the installed CLI version means that standard package management tools may not reflect the actual code running on the host. This divergence complicates auditing and compliance efforts, as the running binary may differ from the version recorded in inventory systems.
The inability to disable the hourly auto-update process poses operational risks for environments requiring strict stability. The daemon’s capacity to force-kill active turns after a short drain period can disrupt critical development workflows without warning. Additionally, the daemon’s retention of initial session environment variables, such as proxy settings, can lead to unexpected network behaviour, where connections bypass intended routing rules or security controls.
The issue highlights a broader tension between convenience and control in developer tools. While a shared, self-updating daemon may benefit remote control scenarios or desktop applications, it conflicts with the expectations of CLI users who anticipate that backend processes should live and die with the terminal window. The lack of an opt-in mechanism for this behaviour in version 0.157.0 has drawn criticism from users who prefer explicit control over background services.
What happens next
- Monitor for official statements from OpenAI regarding changes to the default daemon behaviour in future releases.
- Review internal policies on the use of CLI tools that install persistent background services without explicit consent.
- Audit existing installations of Codex CLI for the presence of the app-server daemon and its associated file copies.
- Evaluate the impact of the daemon’s environment pinning on network proxies and security configurations within your organisation.
What to do and how to stay safe: OpenAI
- Verify the version of Codex CLI installed on all development workstations and check for the presence of the app-server daemon.
- Review network logs for unexpected outbound connections originating from the Codex daemon, particularly if proxy settings have changed.
- Ensure that users are aware of the daemon’s self-updating capability and its potential to disrupt active sessions.
- Once the vendor provides an update or configuration option to disable the default daemon start, apply it to maintain control over background processes.
Step-by-step guide: Shadow AI usage: how to control unmanaged model access in your firm
General security guidance from the AppSec Scoop newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Does the Codex CLI daemon update itself automatically?
Yes, version 0.157.0 includes a detached updater that checks for updates hourly and restarts the backend, which can force-kill active turns.
Can users disable the auto-starting daemon in version 0.157.0?
According to the report, the daemon starts by default and the auto-update mechanism cannot be disabled, though users can manually stop the daemon.
How does the daemon handle proxy settings?
The daemon pins the environment variables from the session that started it, meaning it retains the initial proxy settings for all subsequent connections.
