My C: drive hit 230 MB free out of 231 GB. I cleared the obvious junk and got 18 GB back. I also silently wiped the mid-flight tool output of every other Claude session running on the box, because they all write to %TEMP%, and I never thought of “clean temp” as a write that touches other processes.

That last sentence is the whole post. On a single-developer machine, deleting temp files is housekeeping. On a machine running a swarm of agent sessions, %TEMP% is shared mutable state, and a recursive delete on it is a write that lands inside every running process at once. I learned that the way you learn most of these things, by doing it and then reading back what I had actually done.

The state I was in

This was the middle of a marathon day. The box was running half a dozen Claude Code sessions in parallel, most of them mid-task on sports SaaS tickets, plus background dispatch runs and the conversation-enrichment cron. The trigger was blunt: a low-disk warning, then Get-PSDrive C reporting 0.23 GB free. There is no graceful degradation at 230 MB free on Windows. Things just start failing to write, and you go find space.

So I scanned. A recursive size-by-folder in PowerShell, which produced so much output the shell could barely buffer it, gave me the hogs:

  • AppData\Local: 44 GB
  • <agent-data-dir>\chrome-claude-sessions: 33.9 GB
  • Recycle Bin: 3.4 GB

Then I did the obvious thing. The cleanup math was straightforward:

  • Recycle Bin: 3.4 GB
  • Temp: ~7 GB
  • npm cache: 2.0 GB
  • Roblox: 5.9 GB

That is about 18.3 GB, and the drive went from 0.23 GB free to 18.5 GB free. Problem solved, on the surface.

Two things went sideways inside that “~7 GB of Temp.”

Friendly fire

%TEMP% on this box is not just OS scratch and stale installer files. Claude Code writes per-session tool-call output under ...\Temp\claude\<project>\<session-id>\. Every running session has its own subdirectory in there, and it writes the output of a tool call to that directory while the call is in flight, before the result is read back into the conversation.

When I cleared %TEMP%, I cleared all of those, not just the one belonging to the session I was working in. Any other session that had a pending tool result on disk at that moment may have lost it. I was thinking “temp files are by definition disposable.” They are, right up until a live process is the thing that put them there and is about to read them back. A file being in a temp directory tells you nothing about whether something is currently depending on it.

This is the part I want to be honest about, because it is the actual lesson. I did not target other sessions. I ran a scoped-feeling command (clear temp) that was globally scoped in effect, on a resource I had stopped thinking of as shared. The blast radius was every concurrent agent on the machine, and I only realized it after the delete, by reading back what was under that path.

The npm cache had its own small tell that points the same direction. npm cache clean --force reported success and left about 2 GB sitting in the folder. The “clean” was a no-op that claimed it worked, and I had to Remove-Item the directory by hand to actually reclaim the space. Reported success is not verified success, even from your package manager.

The panic delete was treating a symptom

Here is the worse problem, and the reason a one-time cleanup was always going to be a bad fix: the 33.9 GB in <agent-data-dir>\chrome-claude-sessions was not stale junk. It was a cache growing under active use, with no retention policy at all.

The numbers are specific and they are bad. That directory held 218 session dirs. 181 of them had been created in the previous 7 days. Each Claude Code launch that spins up the chrome profile drops roughly 157 MB there and never cleans it up. At that rate it refills the disk in a matter of weeks, not months. Deleting it once buys you maybe a month, and then you are back at 230 MB free running the exact same fire drill, probably mid-task again, probably under live sessions again.

A panic delete on a directory that regrows 157 MB per launch is not a fix. It is a recurring chore you have signed yourself up for, with collateral damage baked into each iteration because you will be doing it under load every time.

The two real fixes

The takeaways split cleanly along the two failure modes.

For the friendly fire: on a multi-agent box, scope your global cleanups. “Clean temp” needs to become “clean the temp entries this session owns, or that no live session owns.” Concretely, that means not running a blind recursive delete on %TEMP%. Enumerate the ...\Temp\claude\<session-id>\ dirs, cross-reference the session IDs against what is currently running, and only touch the orphans. Or relocate the volatile per-session scratch off the shared path entirely so a disk cleanup cannot reach it. Either way, stop treating %TEMP% as inert. On this kind of machine it is live shared state, and a delete is a write.

For the cache bloat: a retention sweep, not a delete. The structural fix is a janitor that caps chrome-claude-sessions by age or count, runs on a schedule, and keeps the directory from ever reaching the size where a human has to intervene at 230 MB free. The whole point is that you never again recover disk by hand while eight sessions are mid-flight, because the only safe time to clean shared scratch is when nothing is using it, and on a box like this there is almost never such a moment.

There was a third thread that came out of the same incident and reinforces all of it. I wanted to relocate Claude’s data directory off C: entirely with a directory junction, mklink /J so apps see a normal folder. You cannot do that live. Every running session holds open file handles on its projects/*/*.jsonl transcripts and lock files, Windows refuses to rename a directory with open handles, and a junction swapped underneath a running process is not re-resolved anyway, the process keeps writing where the handle was opened. So that move got staged behind an abort-guarded script that refuses to run if it sees a claude process, and the actual migration has to happen cold, with every window closed. Same underlying truth: shared, live state does not tolerate being modified out from under the processes using it.

The takeaway

On a multi-agent box, %TEMP% is shared mutable state. “Clean temp” is not housekeeping, it is a write that touches every running process, so scope it to what you actually own. And when a cache is the real problem, the fix is a retention policy that runs while the directory is small, not a panic delete that runs while it is huge and everything is live. The cleanup you run at 230 MB free is the most dangerous one you will ever run, because that is exactly when the machine is busiest and you are least careful. Build the janitor so you never get there.