this looks like a bug, but even normal happy-path codex creates many GB of logs, openai apparently considers this fine bc it's been going on for months
two things help:
1. fs-level compression, I use ZFS bc Btrfs has massive contention problems with concurrent Rust builds
I'd been running into a lot of disk pressure on my system from agents running. I discovered two main causes:
- my approach to using git worktrees for all work. Not entirely surprising, the duplicated build artifacts in each worktree being the main culprit here. There were some limited gains to be had by just being more efficient with how builds were managed but ultimately I just had to limit the number of concurrent features I was working on in a couple of particularly large repos.
- more insidious was the fact I was actually hitting memory limits more than I realised and causing my mac to have to swap heavily. The system was surprisingly still quite performant while this was happening... until it wasn't. Unfortunately as best I can tell the only "fix" when this happens is to restart the machine. There's no way to have the system reclaim any of the swap space once it's written to disk. Which if you have it thrash a couple of times a day (especially easy if you leave something running overnight) adds up very quickly.
switching to copy on write worktrees is the biggest game changer it should become common knowledge pretty soon and it's already available on most operating systems
Yeah mole is brilliant, I just discovered it days after paying for Daisydisk and haven't used Daisydisk since. Mole freed up 80GB on my laptop the first time I ran it.
If OpenAI's super-intelligence can solve Navier-Stokes why can't they fix this stupid bug that ate up 330GB of my Mac's disk space? come one please triage your github issues?
>
If OpenAI's super-intelligence can solve Navier-Stokes why can't they fix this stupid bug that ate up 330GB of my Mac's disk space?
Because the former can be marketed very prestigiously, the latter hardly can.
According to https://www.briefia.fr/en/article/openai-revendique-la-resol... it is estimated that solving Navier-Stokes did cost OpenAI 40 million USD. I would bet that if OpenAI spent the same amount of money using its super-intelligence to fix this bug, this would work.
I'm working on a side project that requires a lot of fine tuning of 3D worlds. Codex ended up creating thousands of artifacts, basically loads of screenshots, in its worktrees, and doesn't clean up after itself.
On a work project, we're moving financial processes from Excel to code, and Codex ended up creating and storing thousands of validation tests unnecessarily. That ended up eating 90GB after we let it loose on a Windows VM that we connected with a custom agent between codex and the VM.
This is definitely a Codex thing and I've never seen this happen in Claude Code or Antigravity.
It's silly I have to tell it to make part of the build process to clean old artifacts or it'll just default to keeping endless folders of test builds and old builds without cleaning them up. The same seems to usually be true with documentation and reference material.
There was a REALLY annoying period where I'd give it full control of a VM and a dedicated project folder and it'd continually refuse to delete anything I asked it to or just silently archive it, even though everything was already in a git repo. It seems to have gotten somewhat better about that now, but I still include "create cleanup scripts to delete unnecessary project content" in the default steps before doing the final merge on a change.
I would argue that the better you can “close the loop” the better. One of my favourite agent activities is giving it a firmware bug and JTAG access + a serial port. That setup means that flashing, debugging (inspecting variables and whatnot, setting breakpoints, etc), and logging can all happen completely autonomously.
Works especially well for transient/hard to repro bugs. It’ll either set breakpoints or write a monitoring script, go to sleep, get woken up by the harness when the bug trips, inspect state, put together a new build based on a hypothesis built from the debugging, flash it, and loop. I’ve had sessions run completely autonomously for over a day and come with a beautiful one-line solution to a gnarly race condition.
In that regard it’s like a human: you can read code all day if you want and you might get somewhere, but being able to inspect what happened, build a new theory, test it, and iterate is way more powerful 99% of the time.
Rust is notorious for this, one thing some people do is force Rust to have a salvage yard for builds so all those dependencies are shared by everything regardless of what you are building or where, but holy moly, can someone make Rust output smaller files? Hard drives are always having some reason to never go down to sane prices.
When I was younger I thought we would be having exabyte hard drives by now.
this looks like a bug, but even normal happy-path codex creates many GB of logs, openai apparently considers this fine bc it's been going on for months
two things help:
1. fs-level compression, I use ZFS bc Btrfs has massive contention problems with concurrent Rust builds
2. Archive your old sessions using something like sessionwiki (https://github.com/youdie006/sessionwiki), I've integrated this into my control plane (https://github.com/BrokkAi/mjolnir/)
I'd been running into a lot of disk pressure on my system from agents running. I discovered two main causes:
- my approach to using git worktrees for all work. Not entirely surprising, the duplicated build artifacts in each worktree being the main culprit here. There were some limited gains to be had by just being more efficient with how builds were managed but ultimately I just had to limit the number of concurrent features I was working on in a couple of particularly large repos.
- more insidious was the fact I was actually hitting memory limits more than I realised and causing my mac to have to swap heavily. The system was surprisingly still quite performant while this was happening... until it wasn't. Unfortunately as best I can tell the only "fix" when this happens is to restart the machine. There's no way to have the system reclaim any of the swap space once it's written to disk. Which if you have it thrash a couple of times a day (especially easy if you leave something running overnight) adds up very quickly.
switching to copy on write worktrees is the biggest game changer it should become common knowledge pretty soon and it's already available on most operating systems
look into ~/.bun/install/cache/@openai folder as well.
for some reason I had 11 separate codex and codex-code-mode-host binaries in mine. each weighing about ~300 MB.
I've been making a lot of use of DaisyDisk over the past year: https://daisydiskapp.com
Mole is ok too
TUI version is free, though there is a paid app if that’s your thing
https://github.com/tw93/Mole
Yeah mole is brilliant, I just discovered it days after paying for Daisydisk and haven't used Daisydisk since. Mole freed up 80GB on my laptop the first time I ran it.
DaisyDisk is such a nice app. I just checked and I purchased it over 11 years ago.
They still update it, it works perfectly, no version 2.0 forced obsolescence. Just a nice, reliable tool.
DaisyDisk is great. Mole also found and deleted a bunch of stuff on my mac from Claude, Gemini, etc.
https://github.com/tw93/Mole
I’ve been using it altogether too much this last month and just bought a 4TB USB4 SSD.
And yes, codex is eating my disk, too. Ironically my solution is mostly codex - I have a task which goes around stomping on detritus.
btw there is a storage section in Chatgpt app settings, showing used space on disk and other related stuff
Good example of SLOP coding from openAI. No wonder they cant keep agents from committing felonies.
If OpenAI's super-intelligence can solve Navier-Stokes why can't they fix this stupid bug that ate up 330GB of my Mac's disk space? come one please triage your github issues?
See this: https://github.com/openai/codex/issues/25921#issuecomment-62...
> If OpenAI's super-intelligence can solve Navier-Stokes why can't they fix this stupid bug that ate up 330GB of my Mac's disk space?
Because the former can be marketed very prestigiously, the latter hardly can.
According to https://www.briefia.fr/en/article/openai-revendique-la-resol... it is estimated that solving Navier-Stokes did cost OpenAI 40 million USD. I would bet that if OpenAI spent the same amount of money using its super-intelligence to fix this bug, this would work.
But seems not to be very economical. :-)
because they'd need to pay a real mathematician to verify the proof they claim.
Are we really surprised that stuff like this happens with AI slop?
Imagine if the vibe-coders get their way and we see this level of bloat and bugginess at EVERY level of the software stack. Everything would collapse.
I'm working on a side project that requires a lot of fine tuning of 3D worlds. Codex ended up creating thousands of artifacts, basically loads of screenshots, in its worktrees, and doesn't clean up after itself.
On a work project, we're moving financial processes from Excel to code, and Codex ended up creating and storing thousands of validation tests unnecessarily. That ended up eating 90GB after we let it loose on a Windows VM that we connected with a custom agent between codex and the VM.
This is definitely a Codex thing and I've never seen this happen in Claude Code or Antigravity.
It's silly I have to tell it to make part of the build process to clean old artifacts or it'll just default to keeping endless folders of test builds and old builds without cleaning them up. The same seems to usually be true with documentation and reference material.
There was a REALLY annoying period where I'd give it full control of a VM and a dedicated project folder and it'd continually refuse to delete anything I asked it to or just silently archive it, even though everything was already in a git repo. It seems to have gotten somewhat better about that now, but I still include "create cleanup scripts to delete unnecessary project content" in the default steps before doing the final merge on a change.
Heh, Claude recently (last couple of weeks) left behind several jj workspaces with many GBs of builds in my env.
Had to tell it to update it's agents.md to not do that...
Codex is obsession with validation tests. It drives me insane.
Agents prefer some sort of tests to check their output.
I would argue that the better you can “close the loop” the better. One of my favourite agent activities is giving it a firmware bug and JTAG access + a serial port. That setup means that flashing, debugging (inspecting variables and whatnot, setting breakpoints, etc), and logging can all happen completely autonomously.
Works especially well for transient/hard to repro bugs. It’ll either set breakpoints or write a monitoring script, go to sleep, get woken up by the harness when the bug trips, inspect state, put together a new build based on a hypothesis built from the debugging, flash it, and loop. I’ve had sessions run completely autonomously for over a day and come with a beautiful one-line solution to a gnarly race condition.
In that regard it’s like a human: you can read code all day if you want and you might get somewhere, but being able to inspect what happened, build a new theory, test it, and iterate is way more powerful 99% of the time.
Rust is notorious for this, one thing some people do is force Rust to have a salvage yard for builds so all those dependencies are shared by everything regardless of what you are building or where, but holy moly, can someone make Rust output smaller files? Hard drives are always having some reason to never go down to sane prices.
When I was younger I thought we would be having exabyte hard drives by now.