My Mac Was Hiding 81 GB in Plain Sight

In September, I opened a disk utility because my Mac had reached the point where the amount of storage in use no longer made sense. I knew my own files could not explain all of it, yet the drive was reporting 348 GB used and only 81 GB available. Somewhere inside years of applications, development tools and temporary files, a large amount of data had accumulated without making itself visible in ordinary use.

The utility gave me the broad shape of the problem, but not enough confidence to act. There were large folders with names such as Containers, Application Support, Developer, .gradle and .cache. Some were clearly technical. Others contained a mixture of disposable files, application state and data that would be painful to lose. A folder being large does not make it safe to delete.

So I gave Codex permission to perform a read-only scan of the drive. The instruction was deliberately narrow: find the large caches and other storage consumers, tell me what they are, and do not delete or modify anything. Claude or another coding agent with controlled access to the local machine could be used in the same way.

That distinction mattered. I was not asking an AI agent to “clean my Mac”. I was asking it to investigate my Mac and explain the evidence so that I could decide what should happen next.

The first scan turned a vague storage problem into a map. Cursor had left a 7.5 GB temporary sandbox cache. XnView had accumulated a 6.1 GB thumbnail database. Ordinary application caches accounted for another 4 GB. Gradle build caches occupied 7.4 GB. Xcode had 11 GB of support files for two versions of iOS on the same iPhone model. Android had two large versions of its Native Development Kit installed. Claude Desktop had a 12 GB local virtual-machine bundle, while Docker was using 23 GB inside its own virtual disk.

Those items looked similar when reduced to folder sizes, but they were not the same kind of thing. The Cursor sandbox directory was temporary. The thumbnail database could be regenerated. Xcode’s older device-support copy was unnecessary once I confirmed which version I still used. The current Android NDK was required by Flutter, so we searched my local projects for version references before removing the older one.

Docker required a different investigation. Its main disk image appeared enormous because it was a sparse file with a much larger maximum capacity than the physical space it currently occupied. Deleting that file directly would have reset Docker and could have destroyed containers, volumes and databases. Once Docker was running, its own storage report showed that roughly 18 GB belonged to an active Kamal BuildKit volume. It was build cache rather than irreplaceable business data, but Docker considered it active, which was why a normal prune would not remove it.

Claude’s 12 GB bundle needed a judgement call too. It contained a local execution environment, a small isolated Linux computer for running commands and code. It was separate from the ordinary chat I used Claude for. The useful question was whether I used any feature that depended on it.

I used Claude for conversation, with Codex as my default coding tool and Cursor also part of that workflow. Keeping that 12 GB local environment therefore made little sense for my use. I removed the bundle, reopened Claude and checked that ordinary chat still worked. That was the confirmation that mattered on my Mac. Someone relying on Claude’s local execution features would need to check those dependencies before removing it. Asking Claude coding questions in chat is different from asking it to execute code in a local workspace.

This is where an AI assistant became more useful than a generic cleaner. It could follow the trail from “this folder is large” to “this is what created it, this is whether it appears active, this is what will probably happen if you remove it, and this is the safer mechanism for doing so”. It could also rescan after each stage instead of treating deletion as a single irreversible leap.

For less technical users, deleting through Finder or the application’s own storage controls may be the better action. Developer tools such as Android Studio provide a manager for installed SDK and NDK versions. Docker has its own inspection and cleanup commands. Xcode can manage simulators. The terminal is not automatically more intelligent simply because it is direct.

The result was larger than I expected. After the first round, used space fell from 348 GB to 301 GB. Removing the Claude virtual machine brought it down to 288 GB. Cleaning the obsolete Docker builder reduced it again to 267 GB. Available space rose from 81 GB to 167 GB.

In total, I removed about 81 GB of data and gained roughly 86 GB of immediately available space. The difference between those figures comes from the way macOS reports reclaimable and available storage. More importantly, I reached that result without guessing that every large directory was rubbish.

There are obvious privacy and safety considerations here. A local agent needs permission to inspect the relevant parts of the drive, and some macOS locations may require Full Disk Access. That permission should be temporary and intentional, not something granted casually. The first scan should also be read-only. Ask for sizes and explanations before asking for deletion commands, and never paste a destructive command unless you have read the complete path and understand what it targets.

A useful starting prompt could be:

Perform a read-only storage audit of my Mac. Focus on caches, temporary files, logs, developer build data, old SDKs, application containers and unusually large files. Do not delete, move or modify anything. Show me the largest locations, explain what created them, separate likely-regenerable data from personal or application data, and flag anything that must be cleaned through its own application. Ask me before suggesting any destructive command.

I would add one more instruction if the agent has access to development projects: search those projects for references before calling an SDK, runtime or toolchain version unused. That simple check prevented me from deleting the Android NDK version my current Flutter installation expects.

This process also changed how I think about storage tools. The visual scanner found the neighbourhood. The agent helped me understand the occupants. Neither should be given unchecked authority to demolish the building.

Most people do not need to become experts in Docker volumes, Xcode device support or sparse disk images. They need a careful way to ask what is consuming the space, what can be regenerated, what contains real state, and what the consequence of deletion will be. That is a good use of an AI coding assistant because the task is investigative before it is technical.

If your computer has slowly filled up, would you trust an AI assistant to perform a read-only audit and explain what it found before you deleted anything?