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...

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

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...

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.

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?

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.

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.

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

Well, OpenAI at least is fine with you using whatever harness you like. Having a crappy first-party one is bad, but an escape hatch puts a floor on it.

Codex is very badly structured. I was an early user with codex. But it mixes state and configuration data; which is why I can't really declaratively manage it in my nix-darwin environment; so abandoned it a while ago. This issue being raised, and the way that the codex development responds back to it makes me not trust their harness ever again. I only use codex in opencode; which seems to be doing OK. At least openai doesn't gate their product to their harness like anthropic.

Not trying to sing praises; i think opencode is doing a bunch of weird stuff too but it's not codex level.

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.

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.

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

My 2-cents: never install those things into your host. A locked down Docker container is the bare minimum. Pin your versions and never update them without checking the changelog.

Cool thing is that I can just ask the llm to modify the harness to what I need. I discovered this daemon thing about two weeks ago and had codex modify it's own custom launcher that I have to bypass the daemon thing. If as a recreational code farmer can do it then most "pros" should be able to handle this and other inconveniences. Cc has been pushing that no scrolling feature that codex recently introduced for a half a year now but again I had them put a stop to that. Software has never been this easy to configure.

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.

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 "${@:-.}"
    }

Continuing to be glad I trust my instincts around bad management making problematic products!

I feel like so many of the new AI tooling is reinventing the wheel. We've figured out how to update software via package managers. Do we need a daemon to continually check for updates and do we need shell scripts to circumvent package managers?

Have a look at https://chatgpt.com/codex/install.sh. It's managing the installation by itself not using existing package managers. There's a good point to making it easy to install, but it leads to managing an installation when you shouldn't need to. Time would be better spent elsewhere and better solutions exist.

Am I the only one thinking this?

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.

In some circles this is called a backdoor.

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.

So, similar as Google and Microsoft have been doing with all their tools?

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.

not to mention the daemon mode breaks a bunch of assumptions one might have about about codex CLI e.g. that codex CLI inherits the env vars of the shell that invokes it.

—no-daemon is the way, but still feels like the noose is tightening …

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.

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

Claude has been doing this already.

ah... so this is why my agents all made a signal noise when i used chatgpt on my phone?

Reminder that OpenAI allows you to use the Pi Coding Agent, which is a lot more lightweight, and in my experience much better than any of the proprietary harnesses.

https://pi.dev/

Claude also now hacks your MacOS to put an "Ask Claude" item into every right-click menu. You can remove it through the system's keyboard preferences.

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.

[flagged]

[flagged]

[flagged]

[dead]

[dead]

[flagged]