I was helping a friend clean up their MacBook remotely over SSH. The machine was nearly dead: 214 MB free. Not gigabytes. Megabytes. So I had an AI coding assistant manage the operation: copy 267 GB of photos to an external drive, verify every file with checksums, then delete the originals.
It worked beautifully. 10,599 photos, all verified byte-for-byte. 333 GB free when we were done.
Then my own Mac started choking.
The cleanup
The process was straightforward. Copy photos to the external
drive. Run rsync -anc to checksum-verify every file
against the original. The -a flag preserves metadata,
-n is dry-run (don't copy anything), and
-c forces checksum comparison instead of just
checking timestamps and sizes. If rsync reports nothing, every
file matches.
All 10,599 files matched. The delete went clean. My friend's MacBook went from life support to breathing easy with over 330 GB free.
Good work all around. Until it wasn't.
The parasite
A day later I noticed my own machine running low on space. I'd had plenty before. I started the usual investigation: What's eating my disk?
The usual suspects showed up. Google Drive cache at 128 GB (annoying but expected). iOS simulator images at 24 GB (Xcode developers know). But the numbers didn't add up. Something else was hiding.
I found it in a temp directory. A single file. 223 GB.
It was the output capture file from the background rsync verification task. The one that ran over SSH. The one where both the source and destination paths were on the remote machine. The SSH tunnel should have carried nothing but rsync's text output: a list of files that differed between source and destination.
Since all 10,599 files matched perfectly, rsync's actual stdout
was essentially just its exit code. Two bytes of useful output.
EXIT:0. Done. Everything matches.
The file holding that output was 223 GB.
What went wrong
The background task system captures command output to a temp file so it can report results later. Normally this is fine. Commands print text, the file holds text. A few kilobytes, maybe megabytes for verbose operations.
But something about this particular combination broke the
assumption. The rsync -anc command over SSH was
processing 251 GB of data on the remote side, computing checksums
for every file. It printed almost nothing. Yet the output capture
file grew roughly proportional to the data rsync
processed, not what it printed.
I don't have a definitive root cause. My best theory: something in the pipe between the SSH session and the output capture was buffering or echoing raw I/O rather than just stdout. The data being checksummed on the remote machine was somehow leaking through the capture layer on the local machine. It's a plausible failure mode for a stream-capture mechanism that's slightly too greedy about what it intercepts.
The file was never cleaned up after the task completed, either. So it just sat there, 223 GB of nothing useful, quietly suffocating my disk.
The irony
An AI assistant whose entire job was to free disk space on one machine silently consumed 223 GB on its operator's machine. The tool doing the cleanup became the mess.
And it was hard to spot because it was hiding among legitimately large things. When you see Google Drive cache at 128 GB and Xcode simulators at 24 GB, your brain accepts "big files in temp directories" as normal. You have to actually add up the numbers and notice they don't account for all the missing space.
The lesson
Three things I took away from this.
First: always monitor the machine you're operating from, not just the one you're operating on. Remote operations have a local cost. SSH tunnels, output capture, logging. Usually it's trivial. Sometimes it's 223 GB.
Second: background tasks that capture output need size limits or rotation. Unbounded file growth is a time bomb. It doesn't matter how unlikely the scenario seems. If a file can grow without limit, eventually it will.
Third: verify your own disk space after large remote operations. I should have checked. I would have caught it immediately. Instead it sat there until I noticed my machine slowing down.
The friend's MacBook is still running great with all that free space. My Mac recovered fine once I deleted the rogue temp file. But somewhere in my task runner's output capture code, there's a bug that turns two bytes of useful output into 223 GB of disk waste. And I still don't know exactly how.
Enjoyed this post?
Get notified when I publish something new. No spam, unsubscribe anytime.