Codex CLI's background daemon hit 600 points on Hacker News. We read our own daemon's overnight log — and inventoried what Claude Code leaves running too

The 30-second version

On 12 October someone posted a GitHub issue to Hacker News under the title “Codex CLI installs a persistent, self-updating background daemon by default.” When we checked on 15 October at 10:22 Pacific it had 606 points and 292 comments. The issue, filed on 25 September against the version its author was running, 0.157.0, describes what opening a Codex session now does: start a background server, copy the whole Codex package into ~/.codex, start an updater that checks hourly and restarts the backend, and keep all of it running after you close the terminal.

We use both Codex and Claude Code on the same Mac, so we checked what each one leaves behind — from process tables, logs, one hour-mark observation and an isolated-home experiment, not from the issue:

• The Codex daemon was already running on our machine, and its log matches the issue. The updater started at 14:37 on 14 October. At 14:42 it logged a successful installer_fetch and installer_run, selected release 0.162.1 (it had started from a copy of 0.161.0), requested a backend restart with a 60-second grace period, and spawned a new backend in the same second. It logged the same fetch-and-run stages five minutes later and then at 47 minutes past every hour, 19 more times by 09:47 the next morning.
• We watched the 10:47 check. At 10:47:34 and 10:47:35 the updater process held TCP connections to port 443 at two addresses, one of them an address chatgpt.com resolved to on our machine, and the log recorded installer_fetch (345 ms) and installer_run (209 ms). The binary embeds the command curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh, which suggests what the stages do. We did not capture what was requested or trace what the run stage executed, and our poll, roughly every 0.8 seconds, sampled no process under the updater other than the backend.
• Closing the terminal does not end it, and stop does not end all of it. In a fresh home directory, opening the TUI started the server and the updater and copied 323 MiB of package; quitting the TUI left both running under PID 1; codex app-server daemon stop ended the server and left the updater alive at least 80 seconds later. With daemon_auto_start disabled, or with codex --no-daemon, opening the TUI started neither and copied nothing.
• Claude Code’s background pieces are different in trigger and in job. A supervisor, claude daemon run, had been running for 19.7 hours, recorded as started on demand by a claude process. Its log shows a login-token check about every eight hours and two self-restarts after the installer swapped the binary. One background session was listed as done and idle, with its state file last updated at 19:50:57 the previous evening, and its process was still alive the next morning — about 330 MiB resident, three TCP connections to port 443 at api.anthropic.com — and we could not establish why.
• Both keep old versions on disk. 644 MiB of Codex release copies next to a 323 MiB npm install; 903 MiB of Claude Code versions, four of them.

Verdict: if you want a CLI whose backend lives and dies with your terminal and runs the binary you installed, Codex gets there with one flag plus a stop command and a manual kill; the --no-daemon option is documented, the flag’s name is not in the four references we checked. Claude Code’s supervisor and updater have documentation pages and named switches; the one anomaly we found is a reason to run claude daemon status now and then. On the installations we examined, both tools update in the background by default.

What the Codex daemon is

Codex’s rich clients — the VS Code extension, the desktop app, Remote Control — talk to an “app-server” process over JSON-RPC. In September OpenAI made the terminal client use a shared app-server too, running as a managed daemon. The merged pull requests tell the story:

The issue’s author lists four behaviors: a daemon that outlives every Codex window, a 374 MB copy of the package under ~/.codex/packages, an updater that checks five minutes after start and then hourly and restarts the backend, and environment variables pinned from whichever session started the daemon. When we checked on 15 October the issue was open with 198 reactions and no comment from a maintainer, and we found no merged change to the default. The first comment in the Hacker News thread took the other side — “this stuff is moving fast, should update automatically… Browsers do it” — and another, by timdorr, said Claude Code has “the same operational model.” Both claims deserve a look at what actually runs.

What its log shows for the last 20 hours

Our Codex CLI is 0.162.1, installed with npm. We changed no setting for this article; the daemon was already there.

The processes. Two, both running from ~/.codex/packages/app-server-daemon/releases/0.162.1-aarch64-apple-darwin/bin/codex rather than from the npm install. The updater’s parent is PID 1; the server’s parent is the updater:

PID 56600  parent 1      started 14 Oct 14:37  codex app-server daemon pid-update-loop
PID 58526  parent 56600  started 14 Oct 14:42  codex app-server --listen unix:// --analytics-default-enabled --managed-daemon

The updater listens on ~/.codex/app-server-daemon/daemon-updater.sock; the server on a socket under /private/tmp/codex-daemon-501/, symlinked from ~/.codex/app-server-control/. No TCP connection was open at the moment of the first snapshot. The server’s own log holds one line from that morning: failed to refresh available models: request timed out, at 09:38:47 — a failed attempt to reach the network, not a captured exchange.

The updater’s log. ~/.codex/app-server-daemon/daemon-updater.stderr.log is a JSON event stream covering 19 hours 10 minutes, from the process start to the last entry before we read it:

So five minutes and five seconds after it started, running from a copy of 0.161.0, the updater installed 0.162.1 and replaced the backend. The configured grace period was 60 seconds; the recorded shutdown stage took 52 ms. What was or wasn’t in flight at that moment is not in the log. The issue links a separate report of this restart interrupting active turns; we did not observe one. After the update came a cycle five minutes later and then one every hour. Across the 20 cycles after the update, installer_fetch took 190 to 465 ms except for 1,399 ms at 06:47 and 4,008 ms at 19:47, and installer_run took 168 to 371 ms except for 1,312 ms at 19:47.

What the hourly check does. Three things we can say, with their sources. From the log: each cycle is a fetch stage followed by a run stage, both reported as succeeded, followed by package_selected with trigger scheduled. From watching the 10:47 cycle on 15 October with lsof and a process poll about every 0.8 seconds: at 10:47:34 the updater process itself held a TCP connection to port 443 at 172.64.155.209, one of the addresses chatgpt.com resolved to on this machine, and at 10:47:35 a second one to 104.18.43.139, which we could not attribute; the log recorded installer_fetch in 345 ms and installer_run in 209 ms; the poll sampled no process under the updater other than the backend, which a 209 ms shell could have slipped between. From the binary: strings finds curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh and, for Windows, irm https://chatgpt.com/codex/install.ps1 | iex, and the Windows issue filed on 13 October describes the updater piping install.ps1 into PowerShell every hour. We did not capture what was requested or trace what the run stage executed; the install-script command is what the strings and the Windows issue suggest, not something we observed running.

Disk. du reported 644 MiB under ~/.codex/packages: a 321 MiB copy of 0.161.0 made when the daemon first started and a 323 MiB copy of 0.162.1 installed five minutes later. The npm installation it was copied from is another 323 MiB. A day later the older copy was still there.

The lifecycle test

To see what starts, what survives and what stop stops, without touching the daemon already running, we pointed Codex at an empty home directory containing only auth.json and a one-line config.toml, opened the TUI in tmux without sending a prompt, and watched the process table.

That reproduces the issue’s “bug found while turning it off.” The command printed "status": "stopped" while the updater process remained; we did not test whether it would have continued its hourly cycle after the server stopped.

Two more runs, each in another fresh home:

• With codex features disable daemon_auto_start run first, which writes daemon_auto_start = false under [features] in config.toml, opening the TUI started no server and no updater, and no packages/ directory was created.
• With the flag at its default and the TUI started as codex --no-daemon, the same: no processes, no copy.

One detail from a first attempt is worth knowing if you script this: with a long home path the updater failed to start with Error: path must be shorter than SUN_LEN, the Unix socket path limit, and only the server ran. In that failed startup attempt, only the app-server remained running after the TUI closed.

Turning it off. codex features list shows the switch:

daemon_auto_start                        stable             true

The codex features command is documented, and the CLI reference documents --no-daemon as “Run the interactive CLI without the shared background server” (it can’t be combined with --remote or codex agents). The flag’s name, daemon_auto_start, is not in the CLI reference, the developer commands page or the configuration reference, which is why people find it in the issue or in features list. To stop a daemon that is already running and keep it from coming back:

codex features disable daemon_auto_start      # future sessions start no daemon (tested)
codex app-server daemon stop                  # stops the server, not the updater (tested)
updater_pid=$(python3 -c 'import json,os;print(json.load(open(os.path.expanduser("~/.codex/app-server-daemon/daemon-updater.pid")))["pid"])')
ps -o user=,pid=,lstart=,command= -p "$updater_pid"   # inspect before acting

The ps line should show your own user and a command ending in app-server daemon pid-update-loop. Only then run kill "$updater_pid" and check that it is gone; if the line shows anything else, or nothing, stop and look.

Deleting the release copies under ~/.codex/packages/app-server-daemon is a separate decision; do it only once nothing is running from them. The 0.162.0 release notes say eligible Remote Control launches use the managed daemon, so if you rely on Remote Control, read its documentation first — we did not test it.

What Claude Code leaves running

Claude Code 2.1.300 on the same Mac, installed with the native installer, examined with the same tools:

A supervisor for background sessions. claude daemon run --origin transient had been running for 70,814 seconds — 19.7 hours — and claude daemon status recorded its origin as “started on-demand by claude (pid 40368)” in one of our project directories. claude daemon --help says: “Service install is disabled in this version — the daemon runs on demand and exits when the last client disconnects.” The documentation describes its job: host the sessions you background with /bg or agent view so they keep working with no terminal open; stop a session’s process after it has been finished and unattached for about an hour; restart a session that exits unexpectedly; and after an auto-update it “restarts itself onto the new version and moves idle sessions over in the background,” while sessions that are working, waiting on you, or attached are not interrupted.

What the log shows it doing. Two self-restarts after the installer changed the binary — at 22:28 on 7 October (2.1.293 to 2.1.294) and 14:36 on 14 October (2.1.294 to 2.1.300), each logged as “binary at ~/.local/bin/claude changed … self-restart” followed by a new supervisor process winning a lock race — and a login-token check every eight hours or so: “auth: proactive refresh starting … scheduling proactive refresh in 28514s”. Whether the restarts left working sessions untouched is the documentation’s claim; our log does not show it either way. The supervisor also keeps one pre-warmed spare worker process ready to become the next background session.

A session process the reaper rule would seem to cover. claude agents --json --all listed one background session running on Claude Code 2.1.293; its worker process had started on 7 October at 17:23, and the roster recorded its dispatch source as our own fleet tooling. At inspection on the morning of 15 October its state file said done, last updated at 19:50:57 on 14 October, and its process was still alive: about 330 MiB resident, three TCP connections to port 443 at api.anthropic.com, almost eight days after it started. It was not pinned. The supervisor’s status output flagged it as “from a different CLI version (most stay attachable and upgrade automatically once idle — exec runs never respawn)”. We did not establish when it actually finished, whether every condition of the one-hour rule applied, or why the process remained. We report it because a process-table check finds this kind of thing and a documentation read does not.

The updater. The documentation says the CLI “checks for updates on startup and periodically while running,” downloads and installs in the background, and updates “take effect the next time you start Claude Code.” It describes a function of the running CLI rather than a separate process, and the supervisor restarting itself afterwards is what our log shows. claude doctor reports the channel and the last attempt; ours was on latest, and the stable channel pointed at 2.1.292 on 15 October. The versions directory held four binaries — 2.1.283, 2.1.293, 2.1.294, 2.1.300 — totalling 903 MiB; the documentation only promises to keep every version when you use a custom launcher, and ours was the installer’s own symlink.

The switches. DISABLE_AUTOUPDATER=1 stops background updates and keeps manual claude update; DISABLE_UPDATES=1 blocks both. Homebrew and WinGet installations do not auto-update by default, and CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1 opts them in. claude daemon stop --any shuts down the supervisor and the sessions it hosts, and --keep-workers leaves the sessions running for the next supervisor, which must start within about a minute on macOS and Linux (run claude agents) or the sessions stop; claude daemon status shows whether one is running and which version; setting disableAgentView to true or CLAUDE_CODE_DISABLE_AGENT_VIEW turns background agents off entirely. All of these are in the documentation.

Side by side

What to do

1. Look before you decide. ps -axo pid,ppid,etime,command | grep -E 'codex app-server|claude daemon|claude bg-' shows what is running and for how long. codex app-server daemon version and claude daemon status tell you which versions. Ten seconds, and the answer is specific to your machine.
2. If you want Codex to live and die with the terminal, disable the flag, stop the running daemon, kill its updater by PID, and confirm with codex features list and the process table. Remote Control’s managed-daemon path may be affected; we did not test it.
3. If you keep the Codex daemon, know that its log shows an update cycle every hour, that the one we watched opened connections to a chatgpt.com address, that a backend restart with a 60-second grace period is part of an update, and that the issue author reports the daemon keeping the first session’s environment, with #53547 as the open report.
4. On Claude Code, pick your updater behavior explicitly. DISABLE_AUTOUPDATER=1 if you pin versions; otherwise the stable channel trails latest by several releases. Run claude doctor to confirm which you have.
5. Check claude daemon status occasionally. If it reports workers from a different CLI version, claude daemon stop --any --keep-workers followed within about a minute by claude agents starts a new supervisor that reconnects to them; the documentation says sessions wait about a minute for a new supervisor before stopping. Verify the supervisor and worker versions separately afterwards; a finished session you no longer need can be removed with claude rm <id>.
6. Reclaim the disk when you want it. ~/.codex/packages/app-server-daemon/releases and ~/.local/share/claude/versions are plain directories. Keep the version the current symlink or launcher points to, and any version a still-running process is using.

What we didn’t test

One machine, one day. A Mac with both tools installed, 19 hours of Codex updater log, one observed hourly check, and a Claude Code supervisor with 19.7 hours of uptime. Linux and Windows behavior comes from the issues, not from us.

What the hourly run executes. We saw TCP connections during one cycle and the log stages, and the install command is in the binary; we did not capture what was requested or trace the run stage.

An update interrupting a turn. The one update in the log happened before we were watching; the issue links a report of interrupted turns, and we did not reproduce it.

Whether the updater keeps its schedule after stop. It was alive at least 80 seconds after the server stopped; we killed it before an hour had passed.

Remote Control and other Codex clients. Homebrew installs, the desktop app, the VS Code extension and Remote Control may start the app-server differently; we only looked at the npm CLI.

Why the finished Claude Code session was still alive, and whether the supervisor’s “exits when the last client disconnects” holds — we did not disconnect all clients or test last-client shutdown; status recorded PID 40368 as the originating process.

Uninterrupted sessions across a Claude Code update. The log shows the supervisor restarting; the guarantee about working sessions is the documentation’s.

Companion reading

• What AI coding agents write to your disk — the files, caches and transcripts each tool leaves behind.
• Claude Code’s disk usage, and how to clean it up — where the gigabytes go and what is safe to delete.
• Claude Code mods can override your deny rules — the other place where “what runs on your machine” turned out to be broader than the settings suggest.
• Codex vs Claude Code usage limits — how the two tools meter what they bill.

Sources

1. OpenAI — CLI: make daemon_auto_start opt-in — a persistent, self-updating background daemon shouldn’t be the default, issue #48195, opened 25 September 2026; open with 198 reactions and 19 comments when checked on 15 October 2026.
2. Hacker News — Codex CLI installs a persistent, self-updating background daemon by default, posted 12 October 2026; 606 points and 292 comments when checked on 15 October at 10:22 Pacific.
3. OpenAI — Add opt-in automatic background server startup, PR #46117, merged 17 September 2026, and Enable automatic daemon startup by default, PR #47179, merged 22 September 2026.
4. OpenAI — Codex 0.162.0 release notes, 8 October 2026: “Skip daemon auto-start for Windows-mounted WSL homes” and “Use the managed daemon for eligible remote-control launches.”
5. OpenAI — Daemon server leaks environment variables across sessions, issue #53547, and Windows: managed daemon updater pipes install.ps1 into powershell.exe every hour, issue #53778, both 13 October 2026.
6. OpenAI — Command line options, the CLI reference entry for --no-daemon and the codex features commands; Developer commands; Codex App Server; and the Configuration Reference. Retrieved 15 October 2026; none names daemon_auto_start.
7. Anthropic — Claude Code: Manage multiple agents with agent view, “The supervisor process,” “Where state is stored,” “Turn off agent view,” and the note on starting a new supervisor within a minute.
8. Anthropic — Claude Code: Set up Claude Code, “Auto-updates.”
9. Anthropic — Claude Code: CLI reference, the claude daemon and background-session commands.
10. Anthropic — Claude Code: Environment variables, DISABLE_AUTOUPDATER, DISABLE_UPDATES, CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE.

Our own measurements, all on one macOS machine on 15 October 2026, Pacific time: process tables with ps and lsof; the Codex daemon’s daemon-updater.stderr.log (14 October 14:37 to 15 October 09:47) and daemon.stderr.log; a process poll about every 0.8 seconds plus lsof -i from 10:46:40 to 10:49:10 around the hourly check; strings on the daemon binary; codex features list; three isolated-home runs of Codex CLI 0.162.1 from npm (default flag, flag disabled, --no-daemon); claude daemon status, claude agents --json --all, ~/.claude/daemon.log, claude doctor; and directory sizes from du -sh. Claude Code 2.1.300, native installer.

FAQ

What does the Codex CLI background daemon actually do? On eligible setups, with daemon_auto_start at its default and without --no-daemon, opening an interactive Codex session starts a shared app-server process and a separate updater process that keep running after you close the terminal. On our Mac, running Codex CLI 0.162.1 from npm, the updater’s log records successful installer_fetch and installer_run stages five minutes after it started, then the selection of 0.162.1 over the 0.161.0 it had copied and a backend restart request with a 60-second grace period; it then logged the same stages again about five minutes later and then every hour. During the one check we watched, the updater process held TCP connections to port 443, one of them at an address chatgpt.com resolved to; we did not trace what the run stage executed. The daemon runs from its own 323 MiB copy of the Codex package under ~/.codex/packages, separate from the npm install.

How do I turn off the Codex daemon? Two things we tested in an isolated home directory: codex features disable daemon_auto_start writes the flag to ~/.codex/config.toml, and after that opening the TUI started no daemon and copied no package; codex --no-daemon does the same for one run and is documented in the CLI reference. For a daemon that is already running, codex app-server daemon stop ended the server in our test but left the updater process alive, so read its PID from ~/.codex/app-server-daemon/daemon-updater.pid, check the command line, and kill that process. The release copies under ~/.codex/packages/app-server-daemon can be deleted once nothing runs from them. The daemon_auto_start flag appears in codex features list but is not named in the CLI reference, the developer commands page or the configuration reference.

Does Claude Code also keep processes running after you close it? It can. The background-session supervisor, claude daemon run, starts on demand when a session is backgrounded, agent view opens, or a client dispatches a background session, and it hosts those sessions so they keep working with no terminal open; its help text says it exits when the last client disconnects. On our Mac one had been running for 19.7 hours, recorded as started on demand by a claude process, together with a pre-warmed spare worker and one background session’s process. Updates are different: the documentation assigns downloading new versions to the running CLI, which installs them in the background to take effect on the next start, and the supervisor’s log shows it restarting itself after the installer swapped the binary.

How do I turn off Claude Code’s background updater and supervisor? Set DISABLE_AUTOUPDATER=1 to stop background updates while keeping manual claude update, or DISABLE_UPDATES=1 to block both. Homebrew and WinGet installs do not auto-update by default. For the supervisor, claude daemon stop --any shuts it down together with the background sessions it hosts, or with --keep-workers leaves the sessions running for the next supervisor, which must start within about a minute on macOS and Linux (run claude agents) or they stop; setting disableAgentView to true or CLAUDE_CODE_DISABLE_AGENT_VIEW turns background agents off entirely. claude daemon status shows whether a supervisor is running and which version it is.

How much disk do the two tools use for their own copies? On our Mac, du reported 644 MiB under ~/.codex/packages for the daemon’s release copies, two versions at 321 and 323 MiB, on top of the 323 MiB npm installation it was copied from. Claude Code’s native installer kept four versions, 2.1.283 through 2.1.300, totalling 903 MiB under ~/.local/share/claude/versions. Neither tool had removed older copies on its own at the time we looked.

Has OpenAI responded to the request to make the daemon opt-in? Not in the issue. When checked on 15 October, the issue opened on 25 September was open with 198 reactions and 19 comments, none from a maintainer. The flag was added as opt-in in a pull request merged on 17 September and switched on by default in one merged on 22 September. Later merged changes skipped auto-start for Windows-mounted WSL homes and added a restart command, and two issues filed on 13 October report the daemon leaking environment variables across sessions and, on Windows, the hourly installer run being flagged by antivirus software.