<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/codex-cli-installs-a-persistent-self-updating-background-daemon-by-default-unpmj86e7" -->

---
title: Codex CLI installs a persistent, self-updating...
description: A GitHub issue on OpenAI's Codex CLI repo reports that since version 0.157.0, simply opening an interactive codex session silently starts a persistent...
canonical: https://daily.dev/posts/codex-cli-installs-a-persistent-self-updating-background-daemon-by-default-unpmj86e7
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: Codex CLI installs a persistent, self-updating background daemon by default | daily.dev
og:description: A GitHub issue on OpenAI's Codex CLI repo reports that since version 0.157.0, simply opening an interactive codex session silently starts a persistent...
og:url: https://daily.dev/posts/codex-cli-installs-a-persistent-self-updating-background-daemon-by-default-unpmj86e7
og:image: https://api.daily.dev/og/posts/UNpMJ86e7.png
og:image:alt: Codex CLI installs a persistent, self-updating background daemon by default
og:image:width: 1200
og:image:height: 630
og:locale: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

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

**[Hacker News](https://daily.dev/sources/hn)** · 3 min read · 0 upvotes · 0 comments

## Summary

A GitHub issue on OpenAI's Codex CLI repo reports that since version 0.157.0, simply opening an interactive codex session silently starts a persistent background daemon (app-server --managed-daemon) that survives window closure, copies the ~374MB platform package into a versioned directory decoupled from the installed CLI, and launches a detached updater that checks for updates hourly and can force-kill active turns on restart. The daemon also pins the environment (e.g. proxy variables) of whichever session first started it, causing later sessions to inherit stale config. The reporter asks that daemon_auto_start default to false, or at least prompt the user once, reserving the persistent daemon behavior for Remote Control or the desktop app. Numerous commenters confirm the CLI becomes unusable on Windows and Linux because of this change, with one comparing the self-updating, environment-persisting daemon behavior to traits of malware.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://github.com/openai/codex/issues/48195>

## Questions this post answers

### Why does Codex CLI 0.157.0 start a background daemon when I just open a session?

Starting with Codex CLI 0.157.0, opening an interactive codex session automatically launches a persistent background daemon (codex app-server --managed-daemon) via the daemon_auto_start setting. It copies the ~374MB platform package into ~/.codex/packages/app-server-daemon/releases/<version>/, runs from that copy decoupled from the installed CLI version, and keeps running after the window closes until manually stopped or the machine reboots.

_daily.dev surfaces reports like this so developers catch unexpected daemon behavior before it disrupts their CLI workflow._

### How do I disable the Codex CLI daemon_auto_start feature?

Set daemon_auto_start = false in config.toml, or run codex features disable daemon_auto_start followed by codex app-server daemon stop. Also manually kill the pid-update-loop updater with pkill -f 'app-server daemon pid-update-loop' since daemon stop does not stop it, then remove ~/.codex/packages/app-server-daemon to fully clear the copied package.

_Developers troubleshooting unexpected Codex CLI behavior can track workarounds like this via daily.dev._

### Why does the Codex CLI background daemon use the wrong proxy settings after I change HTTPS_PROXY?

The Codex app-server daemon pins the environment variables of whichever session first started it, including HTTPS_PROXY, so it keeps using the first session's proxy configuration for all outbound connections regardless of what later sessions set. This same root cause is linked to related bugs where hooks receive the daemon's cwd or cannot identify the client terminal instead of the active session's.

_Anyone debugging stale environment variables in long-lived daemons can follow issues like this on daily.dev._

## Community take

How the wider developer community reacted, aggregated from 1 discussion and 191 comments across hackernews (as of 2026-10-12).

**TL;DR:** Developers describe Codex CLI (and competing agent harnesses) as buggy, bloated, and poorly engineered, with the undisclosed background daemon and auto-update behavior cited as emblematic of rushed, user-hostile design; several say they now sandbox or containerize it rather than trust it directly.

**Sentiment:** 10% positive · 25% mixed · 65% skeptical

**The case for**

- A few argue auto-updating is reasonable since the space moves fast and browsers already do it.
- Some praise the underlying model capability even while criticizing the harness/UX around it.

**The pushback**

- Many report the CLI silently bloats disk usage with old versioned binaries, sometimes 10-20GB+.
- Multiple people say recent updates repeatedly break basic functionality (scrolling, login, sandboxing, subagents).
- Several compare the self-updating, environment-persisting daemon to rootkit/malware-like behavior and distrust running it unsandboxed.
- Commenters feel these tools leave behind garbage files and lack cleanup, comparing it to 'fighting fire by employing an arsonist.'
- People see the UX/quality issues as reflecting rushed, immature engineering practices across LLM coding tools generally, not just Codex.

**By community**

- hackernews (skeptical): Extensive thread venting about Codex's bloat, instability, and the daemon/auto-update behavior, with several explicit malware/rootkit comparisons and workarounds involving Docker or bubblewrap sandboxes.

**Hottest debate:** Whether the poor UX/engineering stems from the harness implementation itself or is an inherent byproduct of AI-generated code and rushed development practices.

**Open questions**

- Will OpenAI actually fix the daemon/auto-update oversight as one commenter (identified as working on it) suggested?
- Is there any harness from a major AI lab that isn't plagued by similar bloat and breakage issues?

**Highlights**

> Sure yea just let sam altman install a rootkit on your box. That's not odd whatsoever. /s
> — [johnnyApplePRNG on hackernews · 1 comments](https://news.ycombinator.com/item?id=50060982)

> All of the harnesses I've used are terrible at cleaning up after themselves. They leave all kind of clutter behind, to the point where on my dev VM, I now have an LLM run once a day to just look through the disk and delete everything that looks like it's leftover garbage. It's like fighting fire by employing an arsonist.
> — [InsideOutSanta on hackernews · 4 comments](https://news.ycombinator.com/item?id=50061105)

> I've used the CLIs for Codex, Gemini and Claude and they all give off the feeling of being on an very rickety, very fast runaway train. You install an update. Oops, they added a sandbox that doesn't work inside a docker container, it's stopped working. You install an update. Oops, you can't log in inside a docker container any more, it's stopped working. You install an update. Oops, they started catching the copy+paste shortcut and replaced it with one that doesn't work. You revert a broken update. Oops, the update changed the format of your login details, the old version can't read them, gotta log in again. You install an update. Oops, can't scroll with the mouse wheel any more. Not showstopping bugs (if you're used to persuading broken oauth logins to work) but it certainly makes updating an "ugh, what have they broken this time?" experience.
> — [michaelt on hackernews · 1 comments](https://news.ycombinator.com/item?id=50062051)

> It also fills up my HD with old versions. I investigated and it took up something like 12 gigabytes in total on my system; which seems insane to me, it’s just a harness? People moan about how badly made Claude code is but Codex seems much worse on every metric
> — [icantevenhold on hackernews · 11 comments](https://news.ycombinator.com/item?id=50060934)

> I haven't worked with the update subsystem before but that seems like an oversight to me. I'm gonna fix it.
> — [charliermarsh on hackernews](https://news.ycombinator.com/item?id=50061555)

**Source threads**

- [hackernews](https://news.ycombinator.com/item?id=50060694) · 295 points · 191 comments

## Similar posts on daily.dev

- [Codex CLI: OpenAI's Open Agent Harness — Installation, Commands, and CI Integration](https://daily.dev/posts/codex-cli-openai-s-open-agent-harness-installation-commands-and-ci-integration-sl98jxtwh) · SitePoint · 1 upvotes · 0 comments
- [Claude Code: Anatomy of a Misfeature](https://daily.dev/posts/claude-code-anatomy-of-a-misfeature-crz1nbr0v) · Hacker News · 0 upvotes · 0 comments
- [Auto mode is now Claude Code's default, and it changes how fast you can actually build](https://daily.dev/posts/auto-mode-is-now-claude-code-s-default-and-it-changes-how-fast-you-can-actually-build-wpcvkw1sy) · XDA Developers · 0 upvotes · 0 comments

---

Tags: [#cli](https://daily.dev/tags/cli), [#openai-codex](https://daily.dev/tags/openai-codex)

[View this post on daily.dev](https://daily.dev/posts/codex-cli-installs-a-persistent-self-updating-background-daemon-by-default-unpmj86e7)

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]}
{"@context":"https://schema.org","@type":"TechArticle","headline":"Codex CLI installs a persistent, self-updating background daemon by default","url":"https://daily.dev/posts/codex-cli-installs-a-persistent-self-updating-background-daemon-by-default-unpmj86e7","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/codex-cli-installs-a-persistent-self-updating-background-daemon-by-default-unpmj86e7"},"datePublished":"2026-10-12T19:19:49.997Z","dateModified":"2026-10-12T20:55:30.187Z","description":"A GitHub issue on OpenAI's Codex CLI repo reports that since version 0.157.0, simply opening an interactive codex session silently starts a persistent...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b6917e802d12794c96a05fe4befe2984?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b6917e802d12794c96a05fe4befe2984?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/codex-cli-installs-a-persistent-self-updating-background-daemon-by-default-unpmj86e7","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"cli,openai-codex","timeRequired":"PT3M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Codex CLI installs a persistent, self-updating background daemon by default"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/codex-cli-installs-a-persistent-self-updating-background-daemon-by-default-unpmj86e7#faq","mainEntity":[{"@type":"Question","name":"Why does Codex CLI 0.157.0 start a background daemon when I just open a session?","acceptedAnswer":{"@type":"Answer","text":"Starting with Codex CLI 0.157.0, opening an interactive codex session automatically launches a persistent background daemon (codex app-server --managed-daemon) via the daemon_auto_start setting. It copies the ~374MB platform package into ~/.codex/packages/app-server-daemon/releases/<version>/, runs from that copy decoupled from the installed CLI version, and keeps running after the window closes until manually stopped or the machine reboots. daily.dev surfaces reports like this so developers catch unexpected daemon behavior before it disrupts their CLI workflow."}},{"@type":"Question","name":"How do I disable the Codex CLI daemon_auto_start feature?","acceptedAnswer":{"@type":"Answer","text":"Set daemon_auto_start = false in config.toml, or run codex features disable daemon_auto_start followed by codex app-server daemon stop. Also manually kill the pid-update-loop updater with pkill -f 'app-server daemon pid-update-loop' since daemon stop does not stop it, then remove ~/.codex/packages/app-server-daemon to fully clear the copied package. Developers troubleshooting unexpected Codex CLI behavior can track workarounds like this via daily.dev."}},{"@type":"Question","name":"Why does the Codex CLI background daemon use the wrong proxy settings after I change HTTPS_PROXY?","acceptedAnswer":{"@type":"Answer","text":"The Codex app-server daemon pins the environment variables of whichever session first started it, including HTTPS_PROXY, so it keeps using the first session's proxy configuration for all outbound connections regardless of what later sessions set. This same root cause is linked to related bugs where hooks receive the daemon's cwd or cannot identify the client terminal instead of the active session's. Anyone debugging stale environment variables in long-lived daemons can follow issues like this on daily.dev."}}]}
```

