AI coding agents filling your Mac's disk: where it goes

Why agents use so much disk

An agent works the way a fast, tireless developer would. It checks out code, installs dependencies, builds, runs tests, and starts again. Many tools give each task its own git worktree so that several can run at once without touching each other's files.

Each worktree is a complete working copy. Each one gets its own node_modules, virtual environment or build folder, and nothing removes them when the task is finished. Twenty finished tasks can mean twenty copies of your project's dependencies.

Find and remove leftover worktrees

In a repository, the first command below lists every worktree git knows about, with its path and branch. It only reads. Run it in each repository you use agents with.

Before removing one, check that its work is safe. Open the folder and run git status. If the branch was merged or pushed and there are no uncommitted changes, nothing is lost by removing it.

The second command removes a worktree's folder. Git refuses if the worktree has uncommitted or untracked changes, which is the protection you want, so do not add --force unless you have looked. The third only clears git's records of worktrees whose folders are already gone. Removing a worktree does not delete its branch.

git worktree list
git worktree remove path/to/worktree
git worktree prune

Session logs and agent data in your home folder

Agents and their command-line tools keep transcripts, history, snapshots of edited files and downloaded tools in hidden folders in your home folder, such as ~/.claude, ~/.codex and ~/.cursor. Editors built on VS Code keep more under ~/Library/Application Support.

The command below lists the hidden folders in your home folder by size, largest last. It only reads.

These folders mix two kinds of data. Logs and transcripts are history: deleting old ones costs you the ability to resume or search those sessions. Settings, credentials and memory files are configuration: deleting them means setting the tool up again. Clear old sessions through the tool's own settings or commands where it offers them, and do not delete the whole folder.

du -sh ~/.??* 2>/dev/null | sort -h | tail -15

Dependencies and build output, multiplied

After removing worktrees you no longer need, the rest of the space is usually in project folders that are still there. Agents often clone repositories into temporary or scratch folders and leave them.

The command below finds node_modules folders under your code folder and sorts them by size. It only reads. Replace ~/Projects with where your code and worktrees live. Python virtual environments, usually named .venv, and build folders such as .build, target and dist follow the same pattern.

Any of these can be deleted in a project that is not in use. The install or build command recreates them.

find ~/Projects -type d -name node_modules -prune -exec du -sh {} + 2>/dev/null | sort -h

Package caches grow faster too

Every install an agent runs adds to the package manager's download cache, and agents install far more often than people do. Test tooling adds its own: Playwright, for example, downloads complete browser builds into ~/Library/Caches/ms-playwright.

These caches are safe to clear with each tool's own command, such as npm cache clean --force, pnpm store prune, uv cache clean or brew cleanup. Each removes downloads only, and the cost is that the next install fetches them again.

Local models

If you run models on the Mac, they are probably the largest single items on the disk. One model is often several GB, and trying a few adds up quickly.

• Ollama keeps models in ~/.ollama/models. The first command below lists them with sizes, and ollama rm followed by a model name removes one.
• Hugging Face libraries cache models and datasets in ~/.cache/huggingface/hub. The second command lists them by size.
• LM Studio keeps its downloads in its own models folder, which you can open and manage from the app.
• Removing a model loses nothing permanent, but it has to be downloaded again if you want it back.

ollama list
du -sh ~/.cache/huggingface/hub/* 2>/dev/null | sort -h

Containers and sandboxes

Some agents run code inside Docker containers. Each image and stopped container stays inside Docker's disk image, which grows and does not shrink by itself.

The first command below shows what Docker is holding. It only reads. The second removes stopped containers, unused networks, dangling images and unused build cache. It does not remove volumes or images that a container still uses. Anything stored only inside a stopped container is lost, so check before running it.

docker system df
docker system prune

Where Diskzy fits

Diskzy maps the whole disk and stays current as files change, which suits this problem: you can see which folder is growing while agents are running. System Data, explained shows developer data and AI models as their own named parts with sizes.

The Clean up tab finds project build folders such as node_modules, .build, Pods and virtual environments wherever they are, and leaves a folder unticked if its project changed in the last 14 days. Package-manager caches are ticked. Ollama, Hugging Face and LM Studio models are listed but unticked, because they would download again. Everything removed goes to the Trash.