On the morning of January 17, 2026, an Apple M1 Max user opened his MacBook to install a macOS point release. The installer refused. The error said "Your Disk Has < 5GB space remaining, unable to install OS updates". He had bought a 1 TB drive specifically to avoid this scenario. The post he later filed on the Anthropic repository began with one sentence that has become the shorthand for an entire category of pain in 2026: "My Apple M1 Max with a 1TB drive failed to update macOS last night due to low diskspace, which surprised me."
He ran DaisyDisk. He found 472 GB of Claude Code files. That bug now has its own issue number, anthropics/claude-code Issue #18869, and it is the cleanest postmortem of how a useful developer tool can quietly eat half a terabyte without telling anyone.
What actually happened on the user's machine?
Reading Issue #18869 end to end, the timeline is roughly this. He had been using Claude CLI heavily for four to five months. His own words: "I think it's been mostly over the past 4 or 5 months that I've heavily used Claude CLI as a regular tool in my dev toolbox." He had not noticed disk pressure during that window. macOS does not warn until the free pool drops under a few gigabytes, and he had a terabyte to absorb the bleed.
Then the OS update needed 25 GB of headroom and could not find it. He opened DaisyDisk. He went looking for the biggest pies on the wheel. His exact line: "I used DaisyDisk to dig into the issue and discovered folders taking up 472GB, both related to Claude CLI."
Two folders. Both Claude. 472 GB.
Where did the 472 GB go, exactly?
The post on the issue tracker is specific. The two culprits are:
| Path | What it is | Why it grows |
|---|---|---|
~/.claude/debug/ |
Verbose Claude Code session logs and diagnostic dumps | One file per session, never garbage-collected by default |
~/Library/Caches/claude-cli-nodejs/<project>/--mcp-logs-<server>/ |
Captured stdout and stderr from every MCP server the CLI spawned | One log stream per MCP server per project, kept indefinitely |
Neither of these is conversation history. Neither is your authentication. Neither is your project memory. Both are diagnostic output that exists in case you need to file a bug report. The product behavior, until very recently, was that these logs grew with no upper bound. A developer who used MCP servers heavily, especially ones that emit verbose JSON-RPC traces, could pile up tens of gigabytes per week without writing a single significant prompt.
The 472 GB number is not the average. The average heavy user lands somewhere between 8 GB and 80 GB. The 472 GB is the long tail. But the long tail is what hits the OS update.
Why did this happen at all?
Three reasons, worth naming because they explain the wider pattern of AI tool disk bloat.
First, the CLI was built to be debuggable. Verbose logging is the right default for a tool still in heavy iteration. Keeping every log forever is the wrong one. The product shipped with the first behavior and not the second.
Second, MCP servers are a sub-tool model. Each MCP server is a child process the CLI talks to over stdio. Capturing that stdio for postmortem analysis is good engineering. Capturing it into a path the user does not know exists is the part that compounds. On a developer with five MCP servers across ten projects, that is fifty independent log streams, each uncapped.
Third, the standard mental model for "where is this tool's data" is ~/.appname. So users grep around ~/.claude, see 12 GB, decide they can live with that, and never know ~/Library/Caches/claude-cli-nodejs/ exists. macOS hides Library from Finder by default. The 460 GB hides behind a folder you cannot see without cmd-shift-period.
How do you fix it without breaking your Claude install?
The wrong fix is rm -rf ~/.claude. That deletes your authentication, your project memory, every conversation transcript, and your settings file in one move. Issue #24207 is the cascade-failure case where unbounded growth eventually destroys auth at zero bytes free. You do not want to be on either side of that line.
The right fix is surgical. Three commands and a settings edit.
# 1. See how much each path is actually using.
du -sh ~/.claude/debug
du -sh ~/Library/Caches/claude-cli-nodejs
# 2. Move the diagnostic logs to Trash, not to /dev/null.
# Both are safe to remove. Claude Code recreates them on next run.
mv ~/.claude/debug ~/.Trash/claude-debug-$(date +%Y%m%d)
mv ~/Library/Caches/claude-cli-nodejs ~/.Trash/claude-cli-nodejs-$(date +%Y%m%d)
# 3. Cap future growth.
# Open ~/.claude/settings.json and add "cleanupPeriodDays": 4
# Example contents:
# {
# "cleanupPeriodDays": 4
# }
That is the whole recovery. On the user from Issue #18869, those two mv calls would have freed 472 GB and the macOS update would have proceeded that night.
A few notes on the commands. Using mv to ~/.Trash instead of rm -rf is deliberate. If you discover later that you needed something inside, you can restore from Trash. Once you empty Trash, the deletion is permanent. The cleanupPeriodDays setting was added by the Anthropic team specifically because of this class of bug, but it is opt-in. Until you write it in, the default is unbounded retention.
How does Claude Code compare to other AI tools on disk?
The 472 GB number is the headline, but Claude Code is not the only tool with this shape of problem. The rough field numbers across a heavily-used developer Mac in 2026 are:
| Tool | Hot path | Typical size after 6 months | Worst observed |
|---|---|---|---|
| Claude Code | ~/.claude/debug plus ~/Library/Caches/claude-cli-nodejs/ |
8 to 80 GB | 472 GB (Issue #18869) |
| Cursor | ~/.cursor/extensions/ .pack files |
4 to 30 GB | 72 files over 1 GB each (forum thread) |
| Codex CLI | ~/.codex/sessions/ plus worktrees |
1 to 15 GB | Tens of GB (Issue #20864) |
| Cline | VS Code globalStorage checkpoints | 2 to 20 GB | Per-checkpoint repo snapshots |
| Ollama | ~/.ollama/models/ |
20 to 200 GB | One 70B model is 40 GB on its own |
The pattern repeats. A tool ships a debug or cache directory that grows by default, the user finds it useful enough to keep running for months, and the directory is in a path Finder hides. The 472 GB story is the most extreme, but the underlying mechanic is industry-wide.
Why is "show me first" the right safety model?
The user in Issue #18869 did the right thing by reaching for DaisyDisk before deleting. DaisyDisk does one thing well: it shows you what is on disk before you act. The problem with DaisyDisk for a developer use case is that it does not know what any of these folders are. It can show you that claude-cli-nodejs is 460 GB. It cannot tell you that the --mcp-logs-* subfolders are safe to remove and that ~/.claude/projects/ is not. The reader has to be a senior dev with the knowledge already in their head.
That is the gap CleanMyDev was built into. It is a Mac cleaner that knows what these paths are because it was built by a developer who lost a weekend to exactly this kind of disk bloat. Every Claude Code path has a label, a last-used date, a size, and a risk class. The MCP logs and debug folders show up green and safe. The auth and projects folders show up red and protected. You see all of it before you click anything.
You also get a layer of muscle memory the CLI does not give you. The CLI will not warn you that your ~/.claude/debug is 80 GB. macOS will not warn you. DaisyDisk will not warn you on its own, you have to remember to run it. CleanMyDev runs on demand or on a schedule and tells you the moment a path crosses a threshold you set.
If you want to read the deeper teardown of where developer disk space hides, see Why I built CleanMyDev: 168 GB of System Data wasn't macOS. If you want the full how-to for the same Claude paths, see Cleaning Claude Code disk usage.
What is the long-term takeaway from the 472 GB bug?
Three things, ordered by how much they matter.
One, every AI coding tool you install in 2026 will write more to disk than it tells you. Treat each new CLI install as a future cleanup task and bookmark its data directory before it grows.
Two, cleanupPeriodDays for Claude Code is a free win. Set it once. Most users never will. You will.
Three, never rm -rf a tool's home directory to fix disk pressure. The cost of one bad delete is higher than the cost of a tenth of a millimeter of disk. Move to Trash, verify, empty later.
The 472 GB user got lucky. He had DaisyDisk installed before the disk filled. He had a 1 TB drive that absorbed the bleed long enough to notice. He documented the exact paths in the issue tracker. Most developers in the same situation lose the weekend to a forensic recovery instead.
What is the next step if this is you?
If your ~/.claude/debug or ~/Library/Caches/claude-cli-nodejs/ is bigger than you expected, run the three commands above and add the settings line. If you would rather see the receipts before you move anything, CleanMyDev opens both folders in one scan for $9.99 once. Move-to-Trash by default, never sudo, Claude Code scanner pre-configured for the paths called out in Issue #18869.