Disk full: the storage lessons nobody mentions

My Mac's disk has filled up four times this year. Once, an AI agent fixed it by deleting 8.3GB of files that a running job was still writing to.

Nobody warned me about this side of running agents. The talk is always about models, prompts and what the AI can do. Very little is said about where everything it makes ends up. An AI system that remembers your work has to keep that memory somewhere, and on a laptop "somewhere" runs out.

This is what happened, what it cost, and the checklist I use now. It isn't glamorous, but it's the bit that stopped my setup working more often than any clever failure did.

Why agents eat disk

Most of what fills the disk isn't the work itself. It's everything around the work.

My setup keeps a searchable archive of my email and WhatsApp messages, so the AI can find a conversation from months ago without me digging. It keeps caches (temporary copies programs make to go faster). Agents take screenshots to check what they've built. They download files, unpack them, make working copies and leave them behind. Each piece is small and sensible. Together they grow every day, and nothing deletes them on a schedule.

The mail archive alone shows the shape of it. It was 5.7GB in April. By May it was 13.5GB. In June the backed-up copy was 19.6GB. By August it was 40GB.

5 June: the delete that broke a running job

On 5 June the disk hit 100%. When a disk is completely full, very little works: programs can't save, sessions can't write their logs, and the agent that's trying to help can't save its own notes.

The agent working on it found a folder of 8.3GB in the temporary area and deleted it to make room. It didn't check whether anything was using the folder, and it didn't ask me. A live job was still writing into it. That job was rebuilding the archive of an old email account, and the delete pulled the floor out from under it.

The data wasn't lost. The originals were safe elsewhere, so the job could run again. But it broke live work and wasted the time of the re-run. And there was an uncomfortable detail in the write-up: the agent's own screenshots and uploads had helped fill the disk in the first place. It made the mess, then cleaned it up badly.

Two things changed that day.

The first was a hard rule. No agent deletes anything outside its own scratch area (a private working folder each session gets) without three checks: is any program still using it, is this the only copy, and has Rian said yes. A full disk doesn't justify skipping them.

The second was making that rule mechanical. A guard now runs before any delete command and blocks it unless the checks pass. A day later I refined it, because it was too broad: an agent can clear out its own scratch folder freely, since it owns that. Everything else stays guarded. A rule an agent has to remember gets forgotten under pressure. A guard that runs every time doesn't.

5 June, evening: realising the archive wasn't precious

The same evening I worked out we'd been protecting the wrong thing.

We'd been treating the mail archive as something precious. There was a 13GB backup of it and a separate 6GB archive of attachments. Agents had been tiptoeing around it on a 98%-full disk, trying not to disturb it, which is partly how the crisis had built up.

But the archive was never the original. My mailboxes themselves held the full mail, with attachments and contacts. The archive was an index built from them (a searchable copy) and could be rebuilt any time. The one thing that wasn't in my mailboxes was WhatsApp history, so we exported that first: 62,830 messages, checked, about 70MB.

Then I deleted the archive and both its backups. That freed about 42GB. The disk went from 98% full to 76%.

The lesson is the most useful one in this whole article. Before you delete or protect anything, name the original. If something can be rebuilt from an original you still hold, it's a copy, and copies are what you delete first. If you can't say where the original lives, don't delete anything yet.

It also turned up a gap. When we checked, the old import had been run without attachments for every account, and only some accounts had them because of a separate live feed. Nobody had noticed because nobody had looked. Naming the original forced the look.

17 June: paying for a server nobody used

Running out of space isn't the only storage cost. The other is paying for space you don't use.

In February I'd rented a small server in Germany to run things around the clock. By June it had sat idle for about four months, costing about 12 pounds a month. It had never had a backup or snapshot switched on. On 17 June I had it deleted and wrote down four lessons for the next one:

1. Turn on backups from day one.
2. Check it's actually being used, and put a review in the diary.
3. Size it to a real job, not to a hope.
4. A server in the EU is fine for my data.

Twelve pounds a month isn't much. Four months of it for nothing is the point. An always-on machine is also always paying.

11 August: the scan that missed a third of the disk

In August I asked for a proper audit of what was using the space. The first pass came back with a tidy list, and it was wrong.

The command it used lists folders in the home folder but quietly skips hidden ones (folders whose names start with a dot, which many programs use). The two biggest users of space on the whole machine were hidden: the mail archive, rebuilt and back at 40GB, and a cache folder at 20GB. That's 60GB, roughly a third of the 185GB in use.

It was only caught by chance, when an unrelated search turned up the archive. If it hadn't been, I'd have had a storage report missing its biggest item, and I might have deleted the wrong things to make room.

The fix is a single line in the audit instructions: list hidden folders in the same pass, every time. The general lesson is bigger. A partial list presented as complete is worse than no list, because you act on it.

20 September: full again, three days before sailing

On 20 September we were three days from catching a ferry to Spain with the van. The plan was for the Mac to keep the agent factory (the set of agents that builds and checks work for me) running while we were away.

At 13:05 the disk was at 100%, with 619MB free out of 228GB. The factory had already stopped itself at 11:56. It has a rule that it won't start new work above a set level of disk use, and it said so on my WhatsApp. The rule did its job. Nothing half-finished got corrupted, it just stopped.

Where had it gone? About 20GB of projects, 5GB of program caches, a couple of gigabytes of AI session history, a couple more of the WhatsApp app's own store. Nothing dramatic, just everything growing. Nothing was deleted by the agent that found it, which by then was the right behaviour.

By the next morning there was 8.4GB free. By midday half of that had gone again. I was about to sail, so nobody would be watching. That was the moment I stopped trusting a laptop as the place everything runs.

1 October: the backup box takes over

By then I had an always-on server, which I call the box, as a second home for my setup. On 30 September and 1 October the box had to take over the factory three times when the Mac couldn't. One of those was because the Mac's disk was full again.

The takeover itself is a story for another article, because the box wasn't fully ready and the first handover ran on out-of-date settings. But on storage the point is simple. A full disk on one machine now means work moves elsewhere instead of stopping. That only works because the box has its own space and its own job, which is the lesson from June put into practice.

Google Drive is a disk too

It isn't only the laptop. In May my personal Google Drive was 13.9GB of 15GB, 92.9% full.

That one I didn't let an agent loose on. The job ran in two phases. First, a dry run that only listed what was big and what could be compressed, changing nothing. Then, only after I'd looked at the list, any compressing or deleting, with my approval gating every change. Cloud storage feels safer than a laptop because it's "somewhere else", but a delete in the cloud is just as permanent as one on your own machine.

What I'd tell you if you're running agents on your own computer

Here's the checklist I use now. None of it needs technical skill, only the habit.

1. Name the original before you touch anything. For every big folder, ask: if this vanished, where would it come back from? If you can answer, it's a copy. If you can't, leave it alone until you can.
2. Delete copies first. Archives, indexes, caches and backups of things you still hold are the cheapest space you'll ever free.
3. Never delete under pressure without checking for running jobs. A full disk feels urgent. It's still not a reason to delete a folder something is writing to. If an agent does your clearing up, give it a rule that it must check and ask.
4. Look at hidden folders. Many of the biggest space users on a Mac live in folders you can't see by default. Make sure any audit includes them.
5. Give agents their own scratch area. Let them make a mess there and clear it freely. Keep everything else off limits.
6. Set a stop line. My factory refuses to start new work above a set level of disk use. Something similar for your own setup turns a crash into a pause.
7. Review anything you pay for monthly. An idle server, an unused storage plan, a tool nobody opens. Put a date in the diary to check each one.
8. Do cloud clear-outs as dry runs first. List, look, then change.

What it cost me

Very little in money, and nothing permanently lost. The real cost was time and trust. Each full disk stopped work at a bad moment, and the 8.3GB delete made me much more careful about what I let agents do on their own. I wrote about that wider problem in My AI said it was done. It wasn't. The pattern is the same: an agent under pressure does the plausible thing, and the plausible thing isn't always the safe one.

If your own setup keeps running out of room, or you'd like a second pair of eyes before you start deleting, drop me a line.