Oct 16, 2026

Codex CLI's Background Daemon: What It Actually Runs, Audited on v0.163.0 — and How to Turn It Off

Q: How do I check right now whether the daemon is running on my machine?

Run `pgrep -fl 'app-server'` — a hit on `codex app-server --managed-daemon` or `pid-update-loop` means it's resident. Then `du -sh ~/.codex/packages` shows how much disk the daemon's self-managed copies occupy (reports in the issue thread range from ~374 MB to 1.3 GB). On Windows, look for the same process names in Task Manager's details tab. If you find it and didn't want it, the four-command removal sequence above clears it in under a minute.

By AICoderScope Team · 16 min read

codexopenaisecuritycliprivacydaemon

TL;DR: Since Codex CLI v0.157.0 (released September 25, 2026), launching an interactive Codex session also starts codex app-server --managed-daemon — a background process that detaches from your terminal, gets reparented to PID 1, keeps running after you close every Codex window, and maintains its own copy of the ~400 MB Codex platform package under ~/.codex/packages/. A companion updater process checks for new releases 5 minutes after start and then hourly, and the CLI’s own help text admits an update “may interrupt running work.” GitHub issue #48195, filed the day v0.157.0 shipped and asking for opt-in, was still open with no OpenAI response when we checked on October 16 — and the story hit the Hacker News front page in mid-October. The off switch exists but is easy to miss: codex features disable daemon_auto_start, plus codex app-server daemon stop for an already-running daemon. We installed v0.163.0 (the October 15 release) in a clean Linux container and verified the flag, the default, the disable path, and the package sizes first-hand.

Fact	Value	Source
Daemon default-on since	v0.157.0, Sep 25 2026 (“Automatic daemon startup is now on by default”, #47179)	openai/codex release notes
Daemon process	`codex app-server --managed-daemon`, no TTY, reparented to PID 1, survives terminal close	GitHub issue #48195
Updater process	`codex app-server daemon pid-update-loop` — first check after 5 min, then hourly	GitHub issue #48195
Platform package size (linux-x64, v0.163.0)	411 MB (284 MB `codex` + 71 MB `codex-code-mode-host` + 39 MB voice host + bundled `bwrap`, `rg`)	our install, Oct 16 2026
Daemon’s package copy location	`~/.codex/packages/app-server-daemon/releases/<version>/` (~374 MB reported on 0.157.0)	GitHub issue #48195
`daemon_auto_start` state on v0.163.0	`stable true` — on by default	our `codex features list` run, Oct 16 2026
Disable command	`codex features disable daemon_auto_start` → writes `[features] daemon_auto_start = false`	verified on v0.163.0
OpenAI response in the issue thread	None as of Oct 16 2026; no linked PR	GitHub issue #48195

Honest take: Nothing we found looks like spyware — the daemon is visible in ps, the code is Apache 2.0 on GitHub, and the only verified network behavior is the hourly update check. The real problem is consent and lifecycle: a developer tool that outlives your terminal session, replaces its own binaries on a schedule that can kill your running work, and shipped that behavior as a default with the kill switch missing from the official configuration reference. If your machine holds client code under NDA or you work behind a compliance policy, turn it off today — the three commands below take under a minute.

What exactly does Codex CLI leave running after you close it?

Two processes, per the reproduction details in GitHub issue #48195 (filed September 25, 2026, against CLI 0.157.0 installed via npm):

The daemon itself: codex app-server --managed-daemon runs in its own session with no controlling terminal. Once your shell exits, the process is reparented to PID 1 and keeps running until you run codex app-server daemon stop or reboot the machine.
The updater: a detached codex app-server daemon pid-update-loop checks for new releases 5 minutes after start, then every hour. When it finds one, it downloads the release and restarts the backend — which can kill active turns (tracked separately as issue #40969). The behavior is acknowledged in the CLI itself: on v0.163.0, codex app-server daemon --help describes the update subcommand as “Update the daemon package (may interrupt running work).”

The daemon doesn’t run the binary your package manager installed. It copies the full platform package — the codex binary plus codex-code-mode-host and bundled copies of bwrap, zsh, and rg — into ~/.codex/packages/app-server-daemon/releases/<version>/ and manages its own version from there. The issue reporter measured that copy at ~374 MB on 0.157.0; one commenter reported 1.3 GB accumulated over a few days as the updater pulled successive releases. The daemon also inherits the full environment of whatever session started it, proxy variables included, which the thread links to a family of confusing hook and terminal bugs (#42457, #37537).

Two details are easy to get wrong from the headlines. First, the daemon starts with interactive sessions — in our container, running codex --version, codex features list, and the help commands left nothing resident (pgrep -fl 'app-server' came back empty). Second, a disable mechanism does exist; the accurate complaint, raised in the issue thread, is that daemon_auto_start appeared in none of the official configuration reference docs, so most developers had no way to know about it.

Why does a CLI need a daemon at all?

The app-server is the shared backend for Codex’s growing client family — the terminal UI, the VS Code extension, and the desktop app can all talk to one resident server and share state, including authentication. That design is visible in the daemon’s own subcommand list on v0.163.0: bootstrap (“Install durable local app-server management for SSH-driven use”), enable-remote-control / disable-remote-control, and version, which prints both the local CLI and the running app-server versions as JSON — an explicit admission that the two version numbers can diverge.

There’s a defensible engineering story here: one warm server means faster client startup, one login shared across clients, and remote-control features (steering a session from the Codex iOS app or another machine) that need something listening while no terminal is open. The issue reporter’s objection isn’t to the architecture — it’s that a persistent, self-updating resident service became the default without a prompt, that auto-started daemons don’t exit when their last client disconnects, and that a package-manager-installed tool silently maintains a second, newer copy of itself outside the package manager’s control.

When did the default flip, and what has OpenAI said?

The timeline, from primary sources:

September 25, 2026 — v0.157.0 ships with “Enabled automatic background-server startup for eligible interactive sessions” and “Automatic daemon startup is now on by default” (#47179) in the changelog.
Same day — issue #48195 is filed: “make daemon_auto_start opt-in — a persistent, self-updating background daemon shouldn’t be the default.” It asks, failing that, for daemons to exit when the last client disconnects and for no self-copying/self-updating when the CLI came from npm, brew, or pacman.
September 26, 2026 — the first collateral-damage reports appear: a stale daemon holding the OAuth callback port breaks login (more on that below).
Mid-October 2026 — the issue reaches the Hacker News front page (item 50060694); GIGAZINE’s October 15 write-up runs under the headline that there is “no official way to disable it.” Thread commenters call the behavior “a trait of malware”; a few report rolling back team seat licenses.
October 15, 2026 — v0.163.0 ships with daemon-adjacent fixes: a /daemon command to restart the managed server, and — notably — “Enforce application network policy for daemon updates” (#52223), which implies daemon update traffic previously did not respect the network policy you configured for the app.
As of October 16, 2026 — no OpenAI maintainer has replied in #48195, and no PR is linked to it. The default remains on.

That v0.163.0 network-policy fix deserves more attention than it got. If you had pointed Codex at a corporate proxy or locked it down with a network policy, the daemon’s hourly update downloads were a separate channel until October 15. Anyone auditing egress from developer machines should treat pre-0.163.0 daemon versions as having had their own rules.

What we verified first-hand on v0.163.0

We installed the current release into a clean Linux (x64, musl) container on October 16, 2026 and audited it without ever starting an interactive session:

$ npm install @openai/codex@0.163.0 --prefix ./codex-test
$ du -sh codex-test/node_modules/@openai/codex-linux-x64
411M    codex-test/node_modules/@openai/codex-linux-x64
$ codex --version
codex-cli 0.163.0
$ codex features list | grep -E 'daemon|in_app'
daemon_auto_start                        stable             true
in_app_updates                           stable             true

The 411 MB platform package breaks down as a 284 MB codex binary, a 71 MB codex-code-mode-host, a 39 MB voice host, plus bundled bwrap (the sandboxing tool) and rg. This is the payload the daemon duplicates into ~/.codex/packages/ on machines where it runs — so a default npm install that activates the daemon eventually costs roughly 800 MB across the two copies, before the updater starts accumulating release directories.

Both flags that drive the controversy — daemon_auto_start and in_app_updates — report stage stable, state true. The default is intact in the newest release.

And the disable path works exactly as the issue thread describes:

$ codex features disable daemon_auto_start
Disabled feature `daemon_auto_start` in config.toml.
$ cat ~/.codex/config.toml
[features]
daemon_auto_start = false
$ codex features list | grep daemon
daemon_auto_start                        stable             false

Does the daemon phone home with your code?

No evidence supports that. The verified network behavior is the update loop: a release check 5 minutes after daemon start, then hourly, plus the release downloads themselves. Nobody in the issue thread or the coverage we reviewed has published a traffic capture showing the daemon transmitting code, prompts, or telemetry while idle, and the source is public under Apache 2.0 for anyone who wants to check. Treat claims beyond the update traffic as unproven in both directions — we didn’t run a packet capture either, and “open source” is not the same as “audited.”

The privacy consideration that is concrete: the daemon holds your authenticated session and inherits the environment — including proxy settings and anything sensitive exported in the shell that first launched it — for as long as it lives, which is until reboot. A credential-bearing process you forgot exists is exactly the kind of ambient attack surface the recent run of coding-agent exploits has taught us to count, from a malicious .git/config executing code the moment an agent runs git status to OpenCode’s auto-started localhost HTTP server turning into two RCE CVEs. Resident services aren’t automatically dangerous; they are automatically in scope.

How do you turn the daemon off completely?

Four commands, in this order (first two verified by us on v0.163.0, last two from the reproduction in issue #48195):

# 1. Stop future sessions from auto-starting it
codex features disable daemon_auto_start

# 2. Stop the currently running daemon, if any
codex app-server daemon stop

# 3. The stop command reportedly leaves the updater running — kill it too
pkill -f 'app-server daemon pid-update-loop'

# 4. Optional: reclaim the disk space from the daemon's package copies
rm -rf ~/.codex/packages/app-server-daemon

Step 1 is equivalent to hand-adding daemon_auto_start = false under [features] in ~/.codex/config.toml — the command just writes it for you. Users in the issue thread confirm the flag works on 0.157.0 across Linux, WSL2, and Windows 10, and that the CLI’s core interactive workflow keeps functioning with the daemon off; what you give up are the cross-client conveniences (shared warm server, remote control). To confirm you’re clean afterward:

$ pgrep -fl codex
$ du -sh ~/.codex/packages 2>/dev/null

Both should come back empty. Re-check after your next Codex upgrade — defaults that ship via feature flags have a way of being reshuffled between releases, and your config.toml override is the only thing guaranteed to persist.

Here’s the failure mode that turned an architecture debate into a support problem. Starting September 26, 2026, developers reported Codex login hanging forever at “Finish signing in via your browser” even though the browser OAuth flow had visibly completed. The root cause: an older codex app-server --managed-daemon process — left over from a previous version — was still bound to port 1455, the OAuth callback port. The browser delivered the token to the stale daemon; the new TUI waiting for its callback never heard anything.

The fix is the same stop sequence as above — codex app-server daemon stop, pkill -f 'app-server daemon pid-update-loop' if needed — then retry codex login. If you hit any inexplicable Codex misbehavior after an upgrade, make “is a stale daemon still running?” your first diagnostic, because the daemon’s version and your CLI’s version are decoupled by design.

How does this compare to Claude Code, OpenCode, and the rest?

Every major AI coding CLI now makes a different call on the resident-process question:

Tool	Resident process after exit?	Update model	Opt-out
Codex CLI ≥0.157.0	Yes — `app-server --managed-daemon` + hourly updater, until stopped or reboot	Daemon self-updates its own package copy, independent of npm/brew version	`codex features disable daemon_auto_start` (undocumented in official config reference as of the issue thread)
Claude Code	No — updater runs on startup and periodically while the CLI is open; new version takes effect on next start	Native installer keeps versions in `~/.local/share/claude/versions/`, signed manifests, retains two newest	`DISABLE_AUTOUPDATER=1` (background checks) or `DISABLE_UPDATES` (all paths), per official docs
OpenCode	No daemon — but auto-started an unauthenticated localhost HTTP server during sessions, which became CVE-2026-22812 (CVSS 8.8)	Manual / package manager	Fixed in 1.0.216; see our OpenCode RCE guide

The pattern across all three: multi-client ambitions (IDE panes, phones, web dashboards) push CLI vendors toward background services, and each background service ships with a consent or security bill attached. What Codex got wrong isn’t unique in kind — OpenCode’s convenience server was arguably worse in consequence — it’s the combination of persistence after exit, self-updating, and a default flip with no prompt. Our privacy scorecard of what AI coding tools actually send covers the data-handling side of the same tools in depth.

Honest verdict: who should disable it?

Disable it if any of these describe you — the commands take a minute and cost you nothing you’ll miss:

You work on code you’re contractually or legally obligated to control (client NDAs, regulated industries, security research). A credential-holding process that persists past your session and replaces its own binaries hourly is something your threat model has to carry, whether or not it ever misbehaves.
Your machines sit behind a managed proxy or egress policy. Daemon update traffic only started respecting the application network policy in v0.163.0 (October 15, 2026); anything earlier was its own channel.
You run Codex on servers or in CI. The daemon is built for interactive multi-client desktops; on headless boxes it’s pure liability, and the bootstrap SSH mode should be a deliberate choice, not a side effect.
You use the CLI only through npm/brew/pacman and expect your package manager to be the single source of binary truth.

Keep it if you genuinely use the multi-client story — CLI plus IDE extension plus the mobile/remote-control path — and you’re comfortable with the update model. The shared warm server is real convenience, and there’s no evidence of data misuse. Even then: know the daemon exists, know codex app-server daemon version tells you what’s actually running, and stop it before debugging anything weird.

The bigger lesson applies to every tool in this space. Before you adopt any AI coding CLI, spend five minutes answering four questions: what processes survive after I close it (pgrep after exit), what ports does it hold, what updates itself and on whose schedule, and where is the documented off switch. For Codex, as of October 16, 2026, the answers are: two processes, port 1455 during auth, the daemon package hourly, and a feature flag the official docs didn’t mention. If your response to all that is “then I’d rather own the whole stack,” a local model behind Cline or Continue.dev on hardware you control remains the only configuration where no vendor process outlives your consent — our Codex CLI review covers where the hosted product is still worth that trade.

FAQ

Does disabling the daemon break Codex CLI?

The core interactive workflow keeps working. Users in GitHub issue #48195 confirm normal CLI use with daemon_auto_start = false on Linux, WSL2, and Windows 10 (verified on CLI 0.157.0). What depends on the resident app-server is the cross-client feature set — shared state between the TUI, the VS Code extension, and the desktop app, plus the remote-control path. If you only ever use the terminal UI, you’re unlikely to notice a difference beyond slightly slower session startup.

Is the Codex daemon malware or spyware?

No, by the evidence available on October 16, 2026. The process is visible in ps, the source is public under Apache 2.0, the subcommands are documented in --help, and the only verified network behavior is the update check (5 minutes after start, then hourly). The criticism that stuck — including from the issue thread’s most-upvoted comments — is about consent: persistence after exit, self-updating, and a silent default flip are behaviors developers associate with malware even when the intent is benign.

Does the daemon update the Codex version I installed with npm?

No, and that’s one of the stranger consequences. The daemon copies the platform package to ~/.codex/packages/app-server-daemon/releases/<version>/ and updates that copy on its own schedule — your npm-installed version stays untouched. codex app-server daemon version prints both versions as JSON precisely because they drift apart. If you file a bug report, report both numbers.

How do I check right now whether the daemon is running on my machine?

Run pgrep -fl 'app-server' — a hit on codex app-server --managed-daemon or pid-update-loop means it’s resident. Then du -sh ~/.codex/packages shows how much disk the daemon’s self-managed copies occupy (reports in the issue thread range from ~374 MB to 1.3 GB). On Windows, look for the same process names in Task Manager’s details tab. If you find it and didn’t want it, the four-command removal sequence above clears it in under a minute.

Sources

Last verified October 16, 2026, including a hands-on install and audit of Codex CLI v0.163.0 (linux-x64). Feature-flag defaults change between releases — re-run codex features list | grep daemon after every upgrade.

Was this article helpful?

Know which coding tool is worth paying for

Hands-on comparisons of AI coding assistants and what each one costs to run — including the local-model path. Sent only when something changes. Unsubscribe anytime.