Yes, Codex CLI can keep a process running after you close the terminal. Since version 0.157.0, an eligible interactive session starts a shared background server automatically, and one command turns that off: codex features disable daemon_auto_start.
This article is for anyone who uses Codex CLI in the terminal most days, especially on a shared build machine or a laptop where background processes and disk space matter. The everyday problem is simple: you close the terminal and assume everything stopped. Since September 25, 2026, the CLI can leave a server running and its package on your disk (338 MB on our Mac) without asking. These three checks show you what your machine is doing, and one command lets you choose the behaviour you want.
Nothing here is broken. Starting the server is the intended behaviour; the only question is whether you want it on your machine. A background server lets several sessions share one connection and recover faster. Still, it starts without asking you. We spent five minutes on our Mac checking what it does, how much disk it takes and how to switch it off. The steps are below.
What changed in Codex CLI 0.157.0
The 0.157.0 release notes, published on September 25, 2026, list it plainly: "Enabled automatic background-server startup for eligible interactive sessions, with recovery choices when server settings are incompatible." The pull request behind it is titled "Enable automatic daemon startup by default".
Before 0.157.0 the CLI stopped when you closed the terminal. From 0.157.0, an interactive session can start a small server in the background, and later sessions talk to that server.
Non-interactive runs such as codex exec are a different path. Our automation calls codex exec many times a day, and on this Mac we found no background server running between those calls.
The Codex CLI 0.157.0 release note that turned on automatic background-server startup (GitHub, captured 2026-11-07).
Check 1: is the feature on?
codex features list | grep daemon_auto_start
On our Mac, on November 7, 2026, with Codex CLI 0.164.0, this printed:
daemon_auto_start stable true
stable is the feature's stage, true is its effective state. So the automatic start is on, which is the default.
Check 2: how much disk does it use?
The server ships as its own package inside your Codex folder:
du -sh ~/.codex/packages/app-server-daemon/releases
Our result: 338 MB, one folder named 0.164.0-aarch64-apple-darwin. On our Mac there was one folder, for 0.164.0. Your number depends on your version and on how many old versions have piled up in that folder.
Check 3: is it running right now?
pgrep -fl codex
If this prints nothing, no Codex process is running. If you see a server process after you closed every terminal, the background server is still alive. You can close it from your process manager, or turn the feature off below and open a fresh terminal.
How do I turn off the Codex CLI background server?
codex features disable daemon_auto_start
codex features list | grep daemon_auto_start
codex features disable writes the change to ~/.codex/config.toml, so it applies to every new session. To undo it later, run codex features enable daemon_auto_start.
If you only want to skip the server for one view, Codex CLI 0.167.0 (November 6, 2026) adds codex agents --no-daemon, which opens the agent command center with an embedded server instead. That does not change the default for normal sessions.
Why it works this way (the system design view)
This is the shared service pattern you already know from other tools: instead of every terminal opening its own connections and state, one long lived process holds them and short lived clients attach to it.
| One process per terminal | Shared background server | |
|---|---|---|
| Start time for the next session | Full start every time | Faster, the server is already up |
| State across sessions | Lost when the window closes | Kept by the server |
| What runs when you are not using it | Nothing | The server |
| Disk | The CLI only | The CLI plus the server package (338 MB here) |
Neither choice is wrong; it depends on the machine. A laptop on battery and a shared build machine usually want the left column. If you open many sessions a day, you will probably prefer the right one.
It is the same one door thinking as in our explainer on which server gets your request: many clients, one place that holds the state.
We use the same one process stays up idea in our server failover piece, where something is always running so the client never waits for a cold start.
Our take
Most write ups of this change just repeat the release note. What they skip is the team question: a default like this should be a decision you write down once, because a shared build machine, a laptop and a CI runner want different answers, and "it was on by default" is not a reason for any of them.
Honest verdict
Good: the background server is documented, the flag has a clear name, and one command switches it off or on. The new --no-daemon option shows the team is giving people more control.
Worth knowing: the automatic start is on by default, the server package takes real disk space (338 MB on our Mac), and the setting lives in ~/.codex/config.toml, where a new teammate will not look first.
What it means for you
- Solo developer, one or two sessions a day: run the three checks once. Keep the default if faster starts matter to you; turn it off if you prefer nothing running in the background.
-
Shared or CI machines: decide the default for the machine, set it with
codex features disable daemon_auto_start(orenable) in your setup script, and document it. -
Low on disk: look at
~/.codex/packages/app-server-daemon/releasesafter upgrades; old version folders add up.
If you run both agents, see how we use Claude Code and Codex CLI together before you settle the defaults for each.
Top comments (0)