Codex CLI installs a persistent, self-updating background daemon by default

Original Article ↗ Hacker News Discussion ↗

OpenAI’s Codex CLI now installs a persistent, self-updating background daemon by default, prompting worries about user control, hidden resource usage, and large amounts of disk space consumed by old versions. Commenters argue that professional tools should not auto-update or run long-lived processes outside the user’s explicit control, especially when they are already buggy and prone to breaking workflows. Many contrast this behavior with traditional OS package managers and lighter third‑party “harnesses,” framing Codex and similar AI tooling (like Claude Code) as emblematic of hasty, LLM-driven development that prioritizes rapid feature growth over stability, transparency, and platform conventions.

Auto-updating daemon behavior

  • Codex CLI now installs a persistent background daemon that auto-updates and keeps old versions.
  • Many see this as user-hostile: it persists after the CLI exits, can surprise users, and is hard to control.
  • Others argue fast-moving AI tooling “needs” auto-updates, likening it to browsers and desktop apps.
  • Several posters insist this might be acceptable only as an explicit opt‑in, not a default, especially for professional tools.

Disk space, performance, and clutter

  • Users report multiple large binaries and many old versions accumulating (several GB to tens of GB).
  • Similar complaints are made about other harnesses (Cursor, Claude Code, VS Code setups) leaving logs, temp dirs, and caches all over the system.
  • Some respond by routinely cleaning via scripts, snapshots, or even using an LLM to identify “garbage” files.

Reliability and software quality

  • Codex CLI, Codex VS Code extension, Claude Code, and other harnesses are described as brittle, frequently regressing on updates, and breaking basic UX (scrolling, copy/paste, subagents, login flows).
  • Many attribute this to “vibe coding” and heavy LLM‑generated code: easy feature accretion, poor architecture, and little manual testing.
  • Others note that buggy flagship harnesses are an honest reflection of the current state of LLM-driven development.

Control, security, and sandboxing

  • Concern that persistent daemons and auto-updates erode user control and resemble backdoors.
  • Several users isolate harnesses in containers, VMs, microVMs, or tools like bubblewrap, or avoid installing them on the host at all.
  • Some report agents reading credentials or running shell commands more aggressively than before, without clear warnings.

Configuration, flags, and workarounds

  • A hidden/undocumented feature flag (daemon_auto_start = false) and --no-daemon are shared as ways to disable the daemon.
  • Worries that defaults and flags may change over time, forcing constant vigilance.
  • Package-manager and Nix users prefer patched builds that strip self-updating behavior.

Alternatives and preferences

  • Lightweight, “minimal” harnesses (e.g., hax, Pi, others) are frequently praised for respecting XDG, avoiding daemons, and behaving like normal CLI tools.
  • Some users revert to manual API use or web UIs, or unsubscribe/delete Codex in response to these changes.