Codex CLI background daemon: what it does, why it starts by default and how to turn it off

Since late September 2026, starting OpenAI's Codex CLI in a terminal also starts a second program you didn't ask for: a background server that keeps running after you close the window and checks for updates every hour. The Codex CLI background daemon became the default in version 0.157.0, published September 25, 2026. On October 12, a Hacker News thread titled "Codex CLI installs a persistent, self-updating background daemon by default" drew 607 points and 292 comments. It linked to a GitHub issue asking OpenAI to make the feature opt-in.

This guide is based on OpenAI's Codex release notes and pull requests, the daemon's README in the openai/codex repository, OpenAI's Codex documentation, the npm registry's records and the contents of the 0.163.0 package (inspected, not run), and the GitHub issues where users reported problems, checked October 16, 2026. The disable steps below come from those sources; where a step comes only from user reports, it says so.

The short version

• What it is: codex app-server --managed-daemon, a shared local server that Codex sessions connect to. It outlives the terminal that started it.
• When it became the default: 0.157.0, published to npm on September 25, 2026 (UTC). The change is PR #47179, "Enable automatic daemon startup by default."
• What it does in the background: by default it checks for updates five minutes after it starts and then every hour, installs them and restarts. A restart can interrupt work in progress.
• How to turn it off: codex features disable daemon_auto_start, then codex app-server daemon stop. To stop the hourly updater too, set "autoUpdateEnabled": false in ~/.codex/app-server-daemon/settings.json.
• What OpenAI hasn't done: explain the default publicly, or list daemon_auto_start in its configuration reference.

What is the Codex CLI background daemon?

Codex's "app server" is the engine behind its interfaces. OpenAI's App Server docs describe it as "the interface Codex uses to power rich clients (for example, the Codex VS Code extension)." It handles sign-in, conversation history, approvals and the agent's events. Until September, a terminal session ran its own app server inside the codex process, and it ended when the session did.

The daemon moves that server into a separate, shared process. According to the daemon README, it backs "the machine-readable codex app-server lifecycle commands used by remote clients such as the desktop and mobile apps." Several features now depend on it:

• codex agents and /agents. OpenAI's command reference says the agents command center "requires a shared local or remote server."
• Remote control. Plain codex remote-control runs "through the managed background server when eligible, with a foreground fallback."
• /daemon. A slash command that opens "background server controls" so you can inspect, update or restart the server.

Why is it on by default?

OpenAI hasn't said. The feature arrived in two steps:

1. September 17, 2026: PR #46117, "Add opt-in automatic background server startup," added the daemon_auto_start flag. It was "disabled by default and available through /experimental," and applied to new, resumed and forked sessions.
2. September 22, 2026: PR #47179 promoted the flag "to stable" and enabled it "by default for eligible interactive launches." It also removed the flag from /experimental, the menu where users could previously turn it off. The PR has no reviews or rationale on its page. It shipped in 0.157.0, whose notes list "Automatic background-server startup for eligible sessions."

OpenAI doesn't define "eligible." PR #46117 names Bedrock sign-in as one launch that stays in embedded mode, and the README says an invocation that sets CODEX_EXEC_SERVER_URL skips the daemon. PR #50555, merged October 3, added another exclusion: Codex homes on Windows-mounted WSL filesystems, which "do not reliably support the required permission semantics."

The third-party claim that daemon auto-start became the stable default in 0.157.0 on September 25 holds up. The npm registry records 0.157.0 at 02:35 UTC on September 25, which was the evening of September 24 in US Pacific time.

What does it do on your machine?

It survives the terminal, not a reboot. The daemon isn't a launchd or systemd service. The README describes it as a "pidfile-backed detached process," and says the updater loop "is not reboot-persistent." After a reboot, it comes back the next time you open an eligible interactive session. The issue that prompted the Hacker News thread, #48195, says it runs "until codex app-server daemon stop or a reboot."

It updates itself. The README says "eligible managed daemons check for updates after five minutes, then hourly by default," and that an update restarts the server, so "active or queued work may be interrupted." The source sets a 60-second default grace period before shutdown, adjustable from 0 to 300 seconds. Issue #48195 describes the process doing this as a detached codex app-server daemon pid-update-loop. It also reports that codex app-server daemon stop leaves that updater running. The current source supports this: the stop command shuts down the server and doesn't touch the updater.

It keeps its own copy of Codex. The README says the daemon runs from ~/.codex/packages/app-server-daemon/current/bin/codex, so its version can differ from the CLI you installed with npm or Homebrew. Issue #48195 puts the copied package at about 374 MB for 0.157.0. Inspecting the 0.163.0 Linux x64 package from npm, without running it, shows about 430 MB of unpacked files, mostly a 297 MB codex binary and a 74 MB codex-code-mode-host. Hacker News commenters reported that old releases were kept on disk and found multiple copies of the binaries.

It freezes its environment. The README warns: "Shared clients use the environment inherited when the daemon started… per-client environment isolation is not provided." In #48195, a per-terminal HTTPS_PROXY setting was pinned this way.

What it doesn't do by default. The daemon talks to clients over a Unix socket in your Codex home folder, not a network port. Remote control is off unless you turn it on: remoteControlEnabled defaults to false in the source. Network-wise, the updater downloads OpenAI's installer and new releases, and 0.163.0 added "Enforce application network policy for daemon updates" (#52223). Separately, 0.161.0 turned on "analytics by default for daemon-launched app servers" (#49426). OpenAI's config reference says analytics.enabled = false turns analytics off.

Problems users reported

• Packaged builds broke. In #48050, Arch Linux users said 0.157.0 wouldn't start unless they used --no-daemon. OpenBSD and NixOS packagers reported the same problem. NixOS's package switched the flag off on September 26 (nixpkgs PR #567051, "codex: disable daemon_auto_start").
• Updates that kill turns. Issue #48195 links the restart behavior to #40969.
• Windows. A commenter on #48195 using Windows 10 LTSC said the daemon got in the way when Codex ran elevated. The README says Windows "requires a non-elevated terminal."

Both issues were opened on September 25 and were still open on October 16, 2026, with no comment from an OpenAI maintainer on either.

How do I turn off the Codex daemon?

Last verified: October 16, 2026, against OpenAI's docs, the source on main and the contents of the Codex CLI 0.163.0 package (published October 15)

OpenAI documents the pieces below, but not in one place. The daemon_auto_start flag name comes from the Codex source, where it defaults to true. OpenAI's configuration reference doesn't list it, though its command reference documents codex features enable and disable for "feature flags stored in $CODEX_HOME/config.toml."

1. Stop it from starting.

codex features disable daemon_auto_start

Or add this to ~/.codex/config.toml:

[features]
daemon_auto_start = false

Users in #48195 and #48050 report that this works. For one run only, OpenAI's command reference documents --disable <feature>, which "translates to -c features.<name>=false"; the #48050 reporter says --disable daemon_auto_start also opened a normal session.

2. Stop the server that's already running. The daemon README documents:

codex app-server daemon stop

3. Stop the self-updater. The README documents a settings file at ~/.codex/app-server-daemon/settings.json. Setting the updater off makes the update loop exit at its next check, according to the source:

{
  "updater": { "autoUpdateEnabled": false }
}

The same block takes "updateIntervalMinutes" if you'd rather keep updates but run them less often. The README notes that this setting doesn't affect an explicit codex update. The workaround posted in #48195, pkill -f 'app-server daemon pid-update-loop', is a user suggestion, not an OpenAI instruction.

4. Skip it for a single session. OpenAI's command reference lists --no-daemon as a global flag: "Run the interactive CLI without the shared background server." It can't be combined with --remote or codex agents. The help text inside the 0.163.0 binary, read from the npm package without running it, adds "even if it is already running":

codex --no-daemon

5. Reclaim disk space (optional). Issue #48195 suggests deleting ~/.codex/packages/app-server-daemon once the daemon is stopped. That step comes from a user, not from OpenAI.

What you give up. With the daemon off, codex agents won't run, because its command center "requires a shared local or remote server." Plain codex remote-control falls back to the foreground. Ordinary terminal sessions keep working in embedded mode, as they did before 0.157.0.

For administrators. The config reference documents check_for_update_on_startup for setups where updates "are centrally managed." It also says [features] in requirements.toml pins "runtime feature flags by the same canonical keys that config.toml uses." It doesn't name daemon_auto_start, so OpenAI hasn't confirmed that a managed pin blocks the daemon for a whole organization.

Should you turn it off?

• Keep it if you use codex agents, remote control from the ChatGPT apps, or several Codex terminals on one machine. Those features are why the server exists.
• Turn it off if you install Codex through a package manager and want that manager to decide the version. Turn it off too if you set proxies or credentials per terminal, run long turns that an hourly restart could cut off, or don't want software running after you close it.
• Either way, the daemon runs agents with your user account's access. The sandbox and approval settings in our Codex explainer still apply to the work the agent does. Our case against unattended agents covers why a process that runs agents out of sight deserves the same scrutiny as the agent itself.

Codex isn't the only coding agent to add background behavior by default this fall. Anthropic's Claude Code began compacting idle sessions in late September without a changelog entry. OpenCode 2.0 now runs as a single shared background service. For a side-by-side look at the tools themselves, see Claude Code vs Codex vs Cursor.

What's confirmed, reported and uncertain

• Confirmed from OpenAI's repository and releases:
  • the opt-in flag (PR #46117, merged September 17)
  • the default change (PR #47179, merged September 22, shipped in 0.157.0 on September 25)
  • daemon_auto_start defaulting to true in the source on October 16
  • the update timing, environment pinning, settings file and lifecycle commands in the daemon README
  • the analytics default (0.161.0)
  • the --no-daemon flag in the 0.163.0 package
• Confirmed from OpenAI's docs: codex features, the global --no-daemon and --disable flags, /daemon, the remote-control commands, analytics.enabled and check_for_update_on_startup.
• Reported by users: the 374 MB copy, the updater surviving daemon stop, the broken distribution packages, the proxy pinning and the extra copies on disk.
• Unknown:
  • why OpenAI made the daemon the default, and what "eligible" covers
  • whether OpenAI will change the default. GIGAZINE reported a commit titled "codex: disable daemon auto-start by default" but gave no PR. No such change appears in OpenAI's repository or 0.163.0's notes as of October 16; the closest match found is NixOS's own packaging change (nixpkgs PR #567051).
  • whether a managed requirements.toml key can block the daemon