Since Codex CLI 0.157.0, opening an interactive session may cause an app-server daemon to run in the background and update itself. The auto-update may even force-kill active turns after a 60-second drain period.
The problem is not limited to sessions being interrupted. The daemon also retains the HTTPS_PROXY, cwd, and environment from the first session, causing subsequent sessions to behave differently from what the user intended. Another issue is that the CLI installed alongside the daemon may be a different binary or version. Frankly, this behavior is better suited to Remote Control or a desktop app than to a CLI, which should start and end with its window.
Opening Codex Starts Other Processes
Users may simply open an interactive session on Codex CLI 0.157.0, only to have an app-server daemon start in the background, along with an auto-update system that may force-kill active turns after a 60-second drain period. Work being typed or running can therefore be interrupted midway.
The impact is not limited to inconvenience. There have been reports that the CLI is unusable on Windows, and that Codex 0.157.0 does not start with the Arch Linux package unless --no-daemon is used. For people who want to open the CLI and start working immediately, a process that appears on its own clearly disrupts the workflow.
What Kind of Tool Is Codex CLI Being Designed to Be?
Codex CLI should follow the lifetime of the window that opened it, use the installed binary, and stop with the session without updating itself in the background. This keeps the program aligned with the environment the user intentionally invoked.
A shared, self-updating daemon is better suited to Remote Control or a desktop app because those are designed to have a service running continuously. If it must be used with the CLI, it should be started explicitly by the user through codex app-server daemon start or bootstrap.
From a Session-Bound CLI to a Daemon That Spans Sessions
Since Codex CLI 0.157.0, opening the TUI can start a daemon in the background, meaning the backend is no longer tied to a single session. As a result, the environment and binary from the first session may affect subsequent sessions.
| Factor | Session-bound CLI | Codex CLI 0.157.0 |
|---|---|---|
| Opening the TUI | Does not start a daemon across sessions | Automatically starts a daemon |
| Backend lifetime | Starts and ends with the window | Continues running in the background |
| Serving binary | The installed and invoked binary | A copy in the managed release directory |
| Background updates | Does not update itself | Can update itself |
| Environment | Uses the current session's environment | May retain values from the first session |
| Disabling daemon_auto_start | Not necessary | The new TUI does not spawn a daemon |
How the Same Problem Appears in Real-World Use
You may open Codex CLI and continue working normally, only for an auto-update to force-kill active turns after a 60-second drain period, interrupting the running work. Meanwhile, users who switch sessions with different HTTPS_PROXY settings may find that the daemon continues using the value from the first session.
In --remote mode, hooks may receive the daemon’s cwd instead of the session’s cwd, and the client’s terminal cannot be identified. This affects work that needs to know the originating location or window. In addition, npm update may not replace a daemon that is still using an older binary, and the Arch Linux package may fail to start unless --no-daemon is used.
Options the Source Identifies as Suitable for Different Tasks
The appropriate model depends on who controls the backend’s lifetime and whether the daemon should be shared across sessions.
| Factor | CLI | Remote Control / desktop app |
|---|---|---|
| Backend lifetime | Starts and ends with the window | Runs as a shared daemon |
| Starting the daemon | The user starts it with start or bootstrap | Suitable for automatic startup |
| Usage model | Uses the installed binary without background updates | Supports a continuously running daemon |
The codex app-server daemon start or bootstrap commands are suitable when users want to start the daemon themselves. The source does not provide information about competitors or other alternative tools outside the Codex ecosystem.
What Works Well and What Takes Control Away from Users
A daemon is suitable for Remote Control and desktop apps because it can run continuously. For the CLI, it can be started explicitly through codex app-server daemon start or bootstrap when necessary.
Pros
- +Suitable for Remote Control and desktop apps
- +Can be started manually when the user wants it
Cons
- −Changes behavior without notification
- −Retains the environment from the first session
- −May run on a binary that does not match the installed one
- −The updater continues running after the daemon is stopped
The Cost That Is Not Included in the Install Command
The cost does not end with npm install -g, because the daemon may force-kill an active turn after the 60-second drain period expires, while the daemon stop command may leave pid-update-loop running. You must kill it manually even after 70 seconds.
The problem also extends to the environment: the daemon remembers HTTPS_PROXY from the first session, and hooks may receive the daemon’s cwd instead of the actual session’s cwd. This makes it difficult to determine who is actually serving the work.
Compatibility issues have also appeared. Codex CLI 0.157.0 may fail to open with the Arch Linux package unless --no-daemon is used. The burden therefore falls on users to check whether the binary, daemon generation, and environment match the ones actually being used.
What Should Change to Make the CLI More Predictable
The most direct solution is to make daemon_auto_start opt-in, with a default value of false, or ask users the first time before enabling it. Opening the CLI should not create a daemon that continues running on its own without prior notice.
The CLI should support externally managed daemon executables so users can control the binary themselves. The daemon stop command must also stop all related updaters, rather than stopping only the app-server while leaving pid-update-loop running.
Another idea that would make verification clearer is an execution receipt when connecting. It should display the CLI version, daemon binary digest, daemon generation, updater state, and inherited environment generation. Users would immediately see which daemon and environment that turn is using.
From “Being Able to Disable the Daemon” to “Knowing Who Is Running the Work for Us”
Setting daemon_auto_start = false prevents a new TUI session from creating a daemon, according to the source, but it still does not answer which daemon version the current session is connected to.
An execution receipt should therefore be provided when connecting, showing the CLI version, daemon binary digest, daemon generation, updater state, and inherited environment generation. Users could then verify which binary the turn is using and which session supplied its environment.