Desktop app: local-agent-mode task sandboxes (~300MB each) never get cleaned up, disk fills up daily
Summary
~/Library/Application Support/Claude/local-agent-mode-sessions/<session-id>/<conversation-id>/ accumulates one local_<uuid> directory per subagent/task run in a Cowork-style session, and these are never deleted after the task completes.
Each local_<uuid> directory is a full clone of ~/.claude (dominated by ~/.claude/plugins, ~300-310MB per copy). In a single active session, ~19 of these were created within a few hours of normal use, accounting for ~8GB. After manually deleting >100GB from this folder, the same session regenerated ~8.8GB again within about an hour of continued use — confirming this is an ongoing leak tied to task/subagent execution, not a one-time accumulation.
Impact
Users doing regular subagent-heavy work (parallel agents, workflows, background tasks) see local disk usage grow by multiple GB per hour of active use, with no automatic cleanup, requiring manual deletion to avoid running out of disk space.
Expected behavior
- The per-task sandbox clone should be deleted automatically when the task/subagent run finishes (success or failure), OR
- The sandbox should avoid a full copy of
~/.claude/pluginsper task (e.g. via a read-only bind mount, overlay/copy-on-write, or hardlinks) since the plugin set is identical across tasks in the same session.
Environment
- Claude desktop app, macOS (Darwin 25.6.0)
- Observed under
~/Library/Application Support/Claude/local-agent-mode-sessions/
Workaround
Running a scheduled local cleanup script that removes local_* sandbox directories once no file inside them has been modified for 12+ hours, since the app itself does not appear to garbage-collect them.
3 Comments
Both my Macbook Pro M1 (16Gb RAM) and Mac Mini (16Gb RAM) have been crashing multiple times a day for just over a month even with as little as two agents. I've been having what sounds like the same problem for a while and made a skill that seems to be helping.
I (re)start the system with over 150GB of free hard disk and run only the minimal amount of programs to keep the system responsive. However memory pressure creeps up as the agents start spawning and soon my system becomes unresponsive and the available space starts to shrink to zero. Eventually I come back to a rebooted machine and logs pointing to Jetsam events, and all kinds of other failure diagnostics that point back to the same route cause: The agents are able to spawn until they induce system memory panic. Subsequent efforts to page away the problem eventually starve the machine of space until crash.
I'm currently 4 days into using my skill and no more crashes. Since using the skill I left my machine running multiple agents overnight and came back to results! The machine memory stays stable despite opening tens of agents concurrently. I've only been able to make the Mac freeze but not crash (hopefully something I'll improve with time).
The skill basically a scheduler based operating system scheduling abstracted behind a simple traffic light system that I've spent way too much time with the agents working on. It works by assessing how stable the system is currently and assessing proactively if it's safe to add another agent to the current load.
Theres a cli that the orchestrator uses that lets it know the state of the OS. It uses this for all it's decisions.
A diagnostics program also runs adjacent to the skill and in the event of a crash you can ask an agent to evaluate the cause of the crash and use the feedback to further tune the skill.
Let me know if it helps you guys:
https://github.com/Wuntenn/claude-agent-resource-management
https://x.com/daronjones/status/2099580645651497330 (drop a like if it helps)
Adding a Windows data point, in case it helps scope this.
Same leak class, a different disk. On Windows 11 Pro (MSIX build) the Cowork sandbox VM has a second disk that shows the same "never cleaned up" behaviour. Its
/sessionsmount (a ~9.8 GB/dev/sdc) accumulates one directory per past session and never reclaims them. On my machine that reached 943 stale session directories dating back about two months, and the disk sat at 100% (9.3 GB of 9.8 GB used, 0 bytes free) for a second consecutive day. A running session cannot self-clear them, because each past session's directory is owned by a different sandbox user.Effect while full:
$HOMEis on that disk, so any write there fails and produces a 0-byte file, and a defaultpip installfails. Scheduled tasks keep running only by writing to the root filesystem instead, which still has headroom.The mounted workspace is safe: it is a separate host share, not on the full VM disk, so real project files are not at risk.
There is a manual control, Help > Troubleshooting > "Free Up Cowork Disk Space" (dialog title "Cowork Disk Cleanup"). It states that it removes caches and temporary files from sessions that are not running and leaves session workspaces alone, and it works. But it is manual only. There is no automatic garbage collection when a session or a scheduled-task run ends, which is the core of this issue, so for scheduled-task users the disk refills between manual cleanups.
Environment: Windows 11 Pro 25H2, Claude desktop MSIX build, Cowork on the local execution mode.
Follow-up on Windows: I ran Help > Troubleshooting > "Free Up Cowork Disk Space" and it returned "No space could be freed. Caches and temporary files are already clean" while
/sessionsstayed at 100% (9.3 GB of 9.8 GB, 0 free). An app-and-PC restart also left it at 100%. So on Windows the supported cleaner does not reclaim the accumulated session directories, and there is no in-app path to recover the space short of the destructive session reset.