DEV Community

Cover image for Your AI coding CLI may still be running after you close it: I reproduced the Codex daemon and wrote an audit
Neeraj Sharma
Neeraj Sharma

Posted on AI-assisted

Your AI coding CLI may still be running after you close it: I reproduced the Codex daemon and wrote an audit

#ai #webdev #security #devops

One of the top Hacker News threads today is a GitHub issue asking OpenAI to make the Codex CLI's persistent, self-updating background daemon opt-in. The report: since version 0.157.0, starting codex interactively also starts a backend that keeps running after you close every terminal, copies about 374 MB of binaries into your home directory and updates itself every hour.

I wanted to see it for myself before writing about it, so I installed Codex CLI 0.157.0 in a clean Linux container with an empty home directory and started the daemon.

What actually runs 

npm i -g @openai/codex@0.157.0
codex app-server daemon start
Enter fullscreen mode Exit fullscreen mode 
Installing daemon from CLI version 0.157.0 into ~/.codex/packages/app-server-daemon...
{"status":"started","backend":"pid","pid":702, ...}
Enter fullscreen mode Exit fullscreen mode

Then the process list:

  PID  PPID  COMMAND
  702     1  ~/.codex/packages/app-server-daemon/releases/0.157.0-.../bin/codex app-server --listen unix:// --managed-daemon
  767     1  ~/.codex/packages/app-server-daemon/releases/0.157.0-.../bin/codex app-server daemon pid-update-loop
Enter fullscreen mode Exit fullscreen mode

Both processes have parent PID 1. No terminal owns them, so closing your shell does not stop them. The second one is the updater. According to the issue, it checks for a new release five minutes after start and then every hour, downloads the whole platform package into a new releases folder and restarts the backend, which can interrupt a turn that is still running. I did not wait an hour to watch that happen.

du -sh ~/.codex/packages
# 374M
Enter fullscreen mode Exit fullscreen mode

That matches the issue exactly: 374 MB, a second copy of the CLI that runs from your home directory instead of from wherever npm, brew or your package manager put it.

The two processes Codex 0.157.0 leaves running, and what each one does

The stop command leaves the updater behind

The issue reports that codex app-server daemon stop does not stop the update loop. I could reproduce that:

codex app-server daemon stop
# {"status":"stopped", ...}

ps -eo pid,ppid,command | grep '[a]pp-server'
#   767     1 .../bin/codex app-server daemon pid-update-loop
Enter fullscreen mode Exit fullscreen mode

The backend is gone, but the updater is still running as an orphan. To clean it up completely you have to kill that process yourself.

Why this matters at work

A background process on a laptop sounds harmless. For a company it raises three questions that usually have clear answers for every other tool on a developer machine:

  1. What version is running? The daemon updates itself from a copy in your home directory, so the version your package manager pinned is not necessarily the version doing the work. The issue reporter found the two could diverge.
  2. What environment does it use? The issue also reports that the daemon keeps the environment of the session that started it. Proxy settings from the first session stuck, and proxy settings in later sessions were ignored, which matters if your company routes traffic through a proxy for inspection.
  3. Who approved it? Security teams generally want to know about software that persists and updates itself, and an opt-out default rather than opt-in means many developers will not know it is there.

None of this means the daemon is malicious. A long-running backend makes sessions start faster and lets several clients share state. The problem is the default, and that the off switch is not where most people would look.

How to turn it off

The feature flag exists, and in 0.157.0 it writes the setting below. The issue reporter confirms that a new session then no longer starts a daemon.

codex features disable daemon_auto_start
# Disabled feature `daemon_auto_start` in config.toml.

cat ~/.codex/config.toml
# [features]
# daemon_auto_start = false
Enter fullscreen mode Exit fullscreen mode

Then stop what is already running, including the orphaned updater:

codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'
Enter fullscreen mode Exit fullscreen mode

If you want the disk space back, the copied package is in ~/.codex/packages/app-server-daemon. Remove it yourself after both processes are gone.

A one-minute audit for every AI CLI

Codex is not the only AI coding tool on most machines, so I wrote a read-only script that checks for orphaned processes from the common ones, the disk their self-managed copies use, and any login items or services that mention them. It changes nothing. It is written for macOS and Linux; I tested it on Linux. Orphans are usually adopted by PID 1, but on desktop Linux and WSL they can be adopted by systemd and on macOS by launchd, so the script checks the parent too.

#!/usr/bin/env bash
# Audit what AI coding CLIs leave running or installed after you close them.
# Read-only. Written for macOS and Linux (including WSL). Usage: bash ai-cli-audit.sh
PAT='codex|claude|cursor|gemini|aider|copilot|windsurf|opencode'

echo "== Orphaned AI tool processes (adopted by init, systemd or launchd, so no terminal owns them)"
ps -eo pid=,ppid=,etime=,command= | awk -v p="$PAT" '
  { line[$1]=$0; par[$1]=$2; exe[$1]=$4 }
  END { for (i in line) if (tolower(line[i]) ~ p) {
          pp = par[i]; pe = exe[pp]
          # orphans are adopted by PID 1, or by systemd --user / launchd on desktops
          if (pp == 1 || pe ~ /(systemd|init|launchd)$/) print line[i] } }' | cut -c1-160

echo; echo "== Disk used by self-managed copies"
for d in ~/.codex/packages ~/.local/share/claude ~/.claude/local ~/.cursor-server; do
  [ -d "$d" ] && du -sh "$d" 2>/dev/null
done

echo; echo "== Codex daemon setting"
if command -v codex >/dev/null; then
  codex features list 2>/dev/null | grep -E '^daemon_auto_start' || echo "codex: flag not found (older version)"
else
  echo "codex not on PATH"
fi

echo; echo "== Login items and services that mention AI tools"
ls ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons 2>/dev/null | grep -iE "$PAT"
command -v systemctl >/dev/null && systemctl --user list-unit-files 2>/dev/null | grep -iE "$PAT"
crontab -l 2>/dev/null | grep -iE "$PAT"
echo; echo "Done. Nothing was changed."
Enter fullscreen mode Exit fullscreen mode

On my test container, after stopping the daemon, it printed:

== Orphaned AI tool processes (adopted by init, systemd or launchd, so no terminal owns them)
  767     1       00:36 ~/.codex/packages/app-server-daemon/releases/0.157.0-.../bin/codex app-server daemon pid-update-loop

== Disk used by self-managed copies
374M    ~/.codex/packages

== Codex daemon setting
daemon_auto_start                        stable             false
Enter fullscreen mode Exit fullscreen mode

The process list check matches on names, so it can also show things you expect, like an editor extension host or a desktop app. Read the list rather than killing everything on it.

Four checks to run on every developer machine with AI coding tools

What I would do this week

  • Run the audit on your own machine, then share it with the team.
  • If you use Codex CLI, decide on purpose whether you want the daemon, and set daemon_auto_start in config.toml either way.
  • Add "does it persist or self-update?" to the questions you ask before approving any AI developer tool.

Checks like this are part of the LLM security work we do at Axionry, and I wrote up how a coding agent is put together in how to build an AI coding agent.

Sources: openai/codex issue #48195, Hacker News discussion. Codex CLI 0.157.0 tested in a clean Linux container on 13 October 2026; the audit script was run there too. I used an AI assistant while drafting this.

Top comments (0)