Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · October 13, 2026 · concept

Codex CLIcodexagent-securityagent-infrastructure

Codex CLI Now Keeps Running After You Close It. Here's How to Check.

Close the terminal and part of OpenAI's coding agent keeps running. Here's what the new default does, why it exists, and how to decide if you want it.

Command-line tools have a simple deal with you. You type a command, it runs, you close the window, it's gone.

Most of us reason about our machines that way without thinking about it. If nothing is open, nothing is running. That assumption is why a GitHub issue about OpenAI's Codex CLI landed on Hacker News on October 12 and passed 560 points: since late September, interactive Codex sessions don't follow that deal anymore by default.

Open a Codex session and it now starts a background server (a daemon, the Unix name for a program that runs on its own without a window) that keeps going after every Codex window is closed. According to the person who reported it, that server also checks for its own updates every hour and swaps itself out.

This means your coding agent has changed category. It used to be a command. Now it behaves more like an installed service, the kind of thing you'd normally choose to set up. That's worth five minutes of your attention, especially on a machine that holds your API keys. If you only want the check, the commands are in "Put this into practice" below.

What actually changed, and when

The timeline is short and public.

  • September 22: Codex CLI 0.156.0 added "opt-in automatic background server startup," a /daemon command to update that server, and a --no-daemon flag to skip it.
  • September 22: OpenAI merged PR #47179, titled "Enable automatic daemon startup by default." It moved a feature flag called daemon_auto_start to stable and turned it on for "eligible interactive launches."
  • September 25: Codex CLI 0.157.0 shipped with the line "Enabled automatic background-server startup for eligible interactive sessions."
  • September 25: The same day, a user filed issue #48195, asking OpenAI to make the daemon opt-in.
  • October 12: The issue hit the Hacker News front page. As of this morning it is still open, with no linked fix.

So this isn't new code. It's a three-week-old default that most people found out about from a forum thread. That gap is the real story.

What the daemon does, in plain terms

Think of the old Codex like a food truck. It shows up when you call it, cooks, and drives away.

The new Codex is closer to a restaurant kitchen that stays lit between orders. Your terminal is just the counter where you place the order. The kitchen (the background server, which Codex calls the app-server) keeps running in the back whether anyone is at the counter or not.

Here's what the issue's author, who reported running Codex 0.157.0 installed through npm on Linux under WSL2 (Windows' built-in Linux layer), observed. These are their findings, not OpenAI documentation:

  • It outlives your windows. Starting an interactive codex session launches a process named codex app-server --managed-daemon. It has no terminal attached and keeps running after all Codex windows close, until you stop it or reboot.
  • It runs its own copy of Codex. The daemon copies the full platform package, about 374 MB, into ~/.codex/packages/app-server-daemon/releases/<version>/ and runs from there. The reporter's point: the version doing the work is no longer the version your package manager installed.
  • It updates itself. A separate pid-update-loop process checks for updates five minutes after start and then hourly, downloads new releases, and restarts the backend. The reporter says that restart can interrupt a task in progress.
  • It remembers the first session's environment. The daemon keeps the environment variables of whichever session started it. In the reporter's case, the first session's HTTPS_PROXY setting got applied to every later session.
  • Stopping it is incomplete. codex app-server daemon stop stopped the server but left the update loop running.

A commenter on Windows 10 confirmed the same behavior on 0.157.0. Several others piled on.

Why OpenAI would want this

It's easy to read the thread and conclude this is sloppy. I don't think that's the whole picture.

A shared background server solves real problems. The release notes around it mention continuing "interrupted work after managed daemon restarts" (0.156.0), making /import work in "local background-server sessions," and offering "explicit recovery for incompatible background servers" (0.157.0). Translated: one warm backend can start sessions faster, share state between them, and survive a closed window without losing your work.

Those are good features. Plenty of developer tools run this way, from language servers in your editor to Docker's background engine.

The problem is the default, not the design. A kitchen that stays lit is great if you own the restaurant. It's a surprise if you thought you'd rented a food truck.

The three costs nobody signed up for

Version drift. When your agent runs from its own copy in ~/.codex/packages/, npm ls -g or your Nix config (a popular way to pin exact tool versions) no longer tells you what's actually executing. If you pin versions for a team, or you need to know which build touched a repo, the answer just got harder to find. For anyone who manages tools through a package manager, that's the part that stings.

Sticky settings. Environment pinning sounds minor until it bites. Picture a laptop where your first Codex session of the day ran inside a corporate VPN shell with a proxy set. Every later session, including the one you open at home, inherits that proxy. Same for any other variable that shaped the first session. The behavior is invisible until a request fails in a way that makes no sense.

A self-updating process next to your keys. Coding agents hold credentials: model API keys, GitHub tokens, whatever your shell exports. A process that keeps running, downloads new code every hour and restarts itself outside your package manager widens what you have to trust. Nothing in the issue suggests anything malicious. But "it updates itself in the background" is exactly the kind of sentence security teams want to approve on purpose, not discover on Hacker News.

Put this into practice

Here's a ten-minute routine. I haven't run the daemon myself for this piece, so the commands below come from Codex's release notes and from the issue thread, and I've said which is which.

1. Check your version. Run codex --version. If it's 0.157.0 or later, the daemon starts by default for what OpenAI calls "eligible" interactive sessions (not every codex command, and some modes are excluded). The current npm release is 0.162.1, and the issue is still open, so assume the behavior holds until OpenAI says otherwise.

2. Look for the process. On macOS or Linux:

ps aux | grep -i "app-server" | grep -v grep
ls ~/.codex/packages/app-server-daemon/releases/ 2>/dev/null

If you see a --managed-daemon process with no Codex window open, or a releases folder you never created, the daemon is live on your machine.

3. Skip it for one session. The release notes for 0.156.0 list a --no-daemon flag that bypasses the shared background server. Use it when you want the old behavior once, for example inside a VPN shell:

codex --no-daemon

4. Turn it off for good. This sequence comes from the issue's author:

codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'
rm -rf ~/.codex/packages/app-server-daemon

A commenter in the same thread reports that setting daemon_auto_start = false in ~/.codex/config.toml also works. Note the third line: since daemon stop reportedly leaves the update loop alive, you kill it by hand. The first line is the one that stops future launches. The last line deletes the cached copies, so skip it if you think you'll turn the daemon back on.

5. Decide as a team, then write it down. If you keep shared dotfiles or a dev container image, put your choice there. On or off is fine. Unknown is the bad state.

What should you expect after step 4? Your next codex session starts its backend fresh, the way it did before 0.157.0, and nothing stays behind when you close the window. You give up whatever speed and session sharing the warm backend gave you. OpenAI hasn't documented exactly what that costs, so watch the first few sessions.

The same check works for every agent you install

Codex isn't special here. It's just the one that got caught in public. Any agent tool can start helpers, add login items or keep a cache of its own binaries, and the habit that catches it is the same.

After installing or updating an agent, take two minutes:

  • List new processes. ps aux sorted by start time shows what launched with the tool and what stayed after you closed it.
  • List new background jobs. On macOS, launchctl list shows launch agents; on Linux, systemctl --user list-units --type=service shows user services. Either one is where a tool would register to start again after a reboot.
  • Look in its home folder. Most agents keep state in a dot-folder (~/.codex, ~/.claude and so on). A packages or releases directory there means the tool manages its own copies.

If something shows up that you didn't expect, it isn't proof of anything bad. It's a question to answer before the tool spends a month on your machine.

Honest limitations

A few things this piece can't tell you.

The specific behaviors (374 MB copy, hourly checks, proxy pinning, the leftover update loop) come from one reporter's investigation on 0.157.0, plus commenters who confirmed parts of it. I found no OpenAI documentation describing them, and versions have shipped since. Some details may already differ on 0.162.1.

The opt-out commands also come from users, not an official guide. --no-daemon is the only switch named in OpenAI's own release notes.

OpenAI hasn't responded in the issue that I could find. Their reasons for making this the default may include things the thread doesn't see, like crash recovery data or support load.

And the HN pile-on has a mood to it. Some of the anger is about agent companies generally, not this flag.

The default is the decision

Every coding agent will face this choice. A resident background process makes tools faster and more resilient, and it moves part of your machine's behavior out of your direct view. Neither answer is wrong.

What changed this month is who made the choice. For most Codex users it got made in a PR they never read, shipped in a release note they never opened. You can make it again, on purpose, in about ten minutes. Run ps after the next agent you install, too. It's a good habit for a year when the tools on our laptops keep getting more ambitious about staying around.

Sources: openai/codex issue #48195 · PR #47179 · Codex CLI 0.156.0 release notes · Codex CLI 0.157.0 release notes · @openai/codex on npm · Hacker News discussion. Versions reviewed: 0.156.0 through 0.162.1, October 13, 2026.

Medium metadata

Title: Codex CLI Now Keeps Running After You Close It. Here's How to Check.

Alternates to test:

  • Codex CLI Is Now a Background Service, Whether You Noticed or Not
  • You Don't Have to Let Codex Keep Running After You Close It
  • Your Coding Agent Is a Daemon Now, and Most Users Never Opted In

Subtitle options:

  • Close the terminal and part of OpenAI's coding agent keeps running. Here's what it does and how to decide. (picked)
  • Codex 0.157.0 made a self-updating background server the default. A ten-minute check for your machine.
  • What the Codex daemon does, why it exists, and the four commands that turn it off.

Description: Since Codex CLI 0.157.0, interactive sessions start a background server that outlives the terminal and updates itself. Here's what it does and how to choose.

Tags:

  1. OpenAI Codex (the exact product readers search for)
  2. AI Agents (the broad builder audience)
  3. Developer Tools (where CLI changes get discovered)
  4. Cybersecurity (the credentials-and-updates angle)
  5. Programming (general reach for working developers)

Article type: A (spike). A real release, a clear behavior change, and commands the reader can run today.

Publish plan: Post at 7 to 8 AM ET, let Medium distribute for 2 to 6 hours, and send to subscribers only if it is performing. Canonical import from the fervorai.dev URL.