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

whimblepop 520 points 265 comments October 12, 2026
github.com · View on Hacker News

Discussion Highlights (20 comments)

dingaling911

This stuff is moving fast, should update automatically. This is kind of standard now. Browsers do it. No reason for harnesses not to do it as well.

icantevenhold

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

timdorr

This is the same operational model as Claude Code. ls ~/.local/share/claude/versions/ ps auxww | grep "claude bg" I see a few prior versions of the Claude Code binary and several running background tasks, without any copy of Claude Code in the foreground. I regularly get a "Update available" message in my Claude Code UI too.

reacharavindh

I’ve been using GPT models via hax[1], a bare bones harness with minimal tools on my system and have the models rely on bash for the most part the last few months. It’s been a breath of fresh air amidst all these overengineered harnesses. If I need special actions, I just make them CLI tools on my Mac and tell the AI model that such a tool exists(via a single line in its system prompt) and that’s it. It’s been very nice. [1] - https://usehax.dev/ No affiliation whatsoever. Just a happy user.

HackerThemAll

Yeah, and for the contrary I spotted Claude app being ugly. When I turned off Claude, then put my computer to sleep and later woke it up, it made my fans spin loudly, and after I checked, there were like 2 dozen Claude processes and a lot of Python. What was it doing - I have no idea, but it was crazy. I'm setting up a VM with nothing but Claude and necessary tools. I feel Claude is not honest with everything it is doing.

esjeon

I think the quality of Codex CLI (and Claude Code) is an honest reflection of the status quo of LLM-driven development. The future doesn’t look really promising.

thebeardisred

It's right about now that having a operating system distro model is great - you get folks who will package the software & test it out, make generally sensible defaults, and generally keep shenanigans like this from going on

quotemstr

Refusal to adhere to the XDG specification is a big signal that the app is going to be a general bull in a china shop. It's not that hard to do OS- and distribution-appropriate package management.

whimblepop

There aren't any documented settings to disable this, but there is a feature flag it currently sits behind. You can flip it in your ~/.codex/config.toml[1]: [features] daemon_auto_start = false There are also some files that it writes to in ~/.codex at startup: pid files, lock files, things like that. You can delete them and replace them with symlinks to /dev/null, then mark those unwritable with `chattr +i` or similar. Presumably then the background daemon will crash on startup, if the feature flag ever goes away. -- 1: https://github.com/openai/codex/blob/0c329ad2c9d5a2592128a1d...

Sha1rholder

Off-topic: I think the front-end quality of ChatGPT/Codex Desktop and Android app is simply dreadful—hard to imagine how such a large number of frequent failures made it into production. Do they not use human testing at all?

grimgrin

while this points it out, i'll show you what I had in place: ~/.codex/config.toml [features] daemon_auto_start = false hell, I also have this redundancy configured in bash: codex() { command codex --no-daemon "${@:-.}" }

warpspin

All I'd want is a CLI with a few tools AND a built-in, properly configurable and working sandbox. Seems that's too much too ask.

piker

It's not necessarily hostility. We considered different updating approaches with our legal IDE where security, stability, etc. are paramount, and having a buggy application out in the wild is user-hostile. Sure, in a dream world we'd say "don't ship until it's perfect", but that's just not realistic. We considered the daemon thing, but ended up with a hard-update check on every boot. It's thus a user choice: if you don't like the automatic updating, you can just not run the application anymore. And even with all that, it's hard to stay on the right side of AV algorithms, etc. We wrote about it here: https://tritium.legal/blog/update

dllu

The daemon has many bugs. For example, when auto-updating, it would randomly ruin the permissions and block the goal as .git became read-only. Generally, it is extremely annoying how many bugs Codex has. I basically can't trust it to execute on any goal since it would often get blocked every few hours due to random bugs. https://github.com/openai/codex/issues/52251#issuecomment-60...

gruntled-worker

You can just copy the executable then run it with --no-daemon, or edit the config equivalently. No autoupdates and no background process. The recent terminal UI changes were more fastidious, but even those are easily disabled with CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 and the /tui command.

ilitirit

I use it at work. On Windows it also launches a new console window every it executes (?) a command. You should definitely disabled this using --no-daemon. I don't know how and why they ruined this CLI with needless "features". It was perfectly usable two weeks ago.

umutsevdi

I discovered this while benchmarking the tool I'm developing. I realized Codex was surprisingly fast after the initial run. Some other harnesses do similar things, so I decided to use bwrap around these tools for accurate benchmarking.

jbverschoor

Sandbox everything if the OS is not doing what it’s supposed to do

ranger_danger

In some circles this is called a backdoor.

Alifatisk

Is anyone using the vscode extension of Codex? Its insane how brittle it is. Just a couple of days ago, it was completely broken for about a week before it got somewhat fixed again. When I say fixed, I mean basic functionality is working again but bugs and regressions are still left. There are multiple issues tracking the same problems. The community have even started to patch the extension themselves as a workaround until its adressed. You know whats even crazier? There are like a new release every other day with lots of commits and changes, yet it still in a bad shape. I have turned off autoupdate for Codex extension for this reason. The only extension I’ve had to. I mean, it doesn’t take that much work to have some tests in the pipeline to make sure the extension continue to work, it almost feels like they are purposely doing this. I have now experienced the consequences of ”move fast and break things”. I realize how much software quality means to me. Its not fun being on the receiving end, especially when it affects my daily workflow. If any of you, see anyone hype up LLMs again, please refer them to the state of Codex vscode extension.

Semantic search powered by Rivestack pgvector
9,270 stories · 87,368 chunks indexed