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.

▲

zamadatix 15 minutes ago | parent | next [-]

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.

▲

majormajor 2 hours ago | parent | prev | next [-]

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

▲

plantain 2 hours ago | parent | prev | next [-]

Codex is obsession with validation tests. It drives me insane.

▲

mattgreenrocks 2 hours ago | parent [-]

Agents prefer some sort of tests to check their output.

	▲	tonyarkles an hour ago \| parent [-]
		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.

▲

giancarlostoro 2 hours ago | parent | prev [-]

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.