OpenAI Codex CLI 0.157.0 Installs Persistent Self-Updating Daemon by Default
A GitHub issue reports that the latest OpenAI Codex CLI version installs a background service that auto-updates and persists after sessions end, prompting user requests for change.

Key points
- Version 0.157.0 installs a persistent daemon that runs independently of the CLI session.
- The daemon copies ~374 MB of files to a local directory and updates itself hourly.
- Users report the daemon retains environment variables from the first launch, bypassing later settings.
OpenAI’s Codex command-line interface version 0.157.0 installs a persistent, self-updating background daemon by default, according to a GitHub issue reported on Hacker News. This behavior changes how the tool operates on Linux systems, including Windows Subsystem for Linux 2, by running services that continue after the user closes the application window.
The daemon, identified as codex app-server --managed-daemon, starts when a user opens an interactive Codex session. It runs in its own session without a terminal interface and remains active until the user explicitly stops it or reboots the machine. The process reparents to PID 1, ensuring it survives the closure of the original CLI window.
Technical Details of the Daemon
The installation process copies the entire platform package, approximately 374 MB in size, into a hidden directory within the user’s home folder. This copy includes the main Codex binary, code mode host, and bundled utilities like bwrap, zsh, and rg. The daemon then runs from this local copy, decoupling the backend version from the CLI version installed via npm.
A detached updater process checks for new releases five minutes after startup and then every hour. When an update is found, it downloads the new release and restarts the backend. This auto-update mechanism can force-kill active turns after a 60-second drain budget and cannot be disabled, according to the issue report.
Impact on User Configuration
The daemon pins the environment variables from the session that initially started it. If a user launches Codex with specific proxy settings, such as HTTPS_PROXY, the daemon retains those settings for all subsequent connections. Later sessions launched with different proxy configurations will still route outbound connections through the initial proxy.
This behavior also affects remote mode hooks, which receive the daemon’s current working directory instead of the session’s directory. Additionally, hooks spawned by the daemon cannot identify the client terminal, breaking terminal-targeting functionality. These issues stem from the daemon operating independently of the interactive session.
What should you do?
Users who have installed version 0.157.0 or later should verify if the daemon is running on their systems. The report suggests that the daemon continues to run until explicitly stopped or until a system reboot occurs. Administrators should monitor for unexpected network connections originating from the Codex process.
What should you do?
What to do and how to stay safe: OpenAI
- Check for running Codex daemon processes using system monitoring tools to ensure they are not persisting after sessions end.
- Review network traffic for unexpected outbound connections from the Codex application, especially if proxy settings have changed.
- Monitor the ~/.codex directory for large file copies and automatic updates that may occur without user interaction.
- Wait for an official update from OpenAI that makes the daemon auto-start opt-in or allows users to disable the background service.
Step-by-step guide: Prompt Injection Warning Signs: How to Spot AI Manipulation
General security guidance from the Threat Times 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, the daemon checks for updates hourly and restarts the backend with new releases, which can interrupt active sessions.
Can users disable the auto-updating daemon in version 0.157.0?
No, the auto-update mechanism cannot be disabled according to the issue report, and the daemon persists until manually stopped or rebooted.
How does the daemon handle environment variables like proxies?
The daemon retains the environment variables from the first session that started it, ignoring settings from subsequent sessions.


