Never let a cleaner run during a build

Every cleanup tool will tell you that build caches are safe to delete because they regenerate. That is true. It stops being true the moment a build is actually running, and most tools have no idea whether one is.

The short answer: a build cache is scratch space for work in progress. Deleting it afterwards costs you a slower next build. Deleting it during costs you the build, and the error you get will not mention the cleaner.

What goes wrong, specifically

Take Xcode. During a compile it writes intermediate object files, module caches and precompiled headers into DerivedData, then links them at the end. Remove that directory halfway through and the linker looks for files that existed a second ago.

The failure is not a clean "file missing". It surfaces as a confusing compiler or linker error, and the natural response is to assume you broke something in the code. People lose an hour to this before the thought "something deleted my build directory" ever occurs.

The same shape of problem applies to a npm install losing its cache mid download, a Gradle build losing its dependency cache, or a Rust build losing its target directory.

Exports are worse

Video and photo work makes this sharper. Premiere, Final Cut, DaVinci Resolve and Lightroom all write render and preview caches while exporting. Delete those mid export and you do not get an error, you get a corrupted or silently wrong output file.

A build that fails is annoying. An export that completes and is quietly wrong is worse, because you may not notice until someone else does.

Why tools get this wrong

Most cleanup tools decide what to delete based on two things: whether the path matches a known cache location, and whether you asked it to run. Neither of those tells you whether the cache is in use right now.

Scheduling makes it likelier, not less likely. A tool that runs every night at two in the morning will eventually run during a long export or an overnight CI job, and by design nobody is watching when it does.

What a tool should actually do

It should look for evidence of work in progress before touching anything, and stand down if it finds any.

In practice that means checking for active build processes, not just installed toolchains. There is a genuine subtlety here that is easy to get wrong: some development tools run a daemon that starts with your editor and never exits. Matching on the daemon rather than the build means the tool thinks a build is permanently in progress, and then it never cleans anything at all. That fails in the safe direction, but it is still broken.

It also means treating creative applications as a reason to stand down, since an export gives very little outward sign that it is happening.

What GuardMac does

It refuses to touch build caches while Xcode, Gradle, Vite, a Next.js build, ninja, swiftc, rustc, cargo, an npm or pod install, or ffmpeg is running. It refuses to touch any cache at all while Final Cut, Premiere, After Effects, DaVinci Resolve, Lightroom, Capture One, Logic or Photos is open, on the basis that an export in progress is invisible from the outside.

It will not delete anything inside a Photos, Final Cut or Lightroom library, even a folder named Cache nested deep within one. It shows you the itemised total before deleting anything. It never touches Documents, Downloads, Desktop, Pictures or Movies, and never empties your Trash unless you ask.

The principle

Safe to delete and safe to delete right now are different claims. Any tool that cannot tell the difference is making the first claim while behaving as though it made the second, and the cost lands on whoever happens to be compiling at the time.

If you are deciding what to clear by hand, the full list of what regenerates and what does not is the companion to this.

Keep reading

• What is safe to delete on a Mac, and what absolutely is not: what regenerates, and what never comes back.
• Memory pressure and swap on a Mac, explained properly: why "memory used" is the wrong number to watch.