[BUG] Cowork Plugin cache never cleaned up per session, causing sessiondata.img to fill up and all new conversations to fail
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
What's Wrong?
Every conversation creates a new user directory under /sessions/<name>/ inside the VM
and caches all installed plugins there. These directories are never cleaned up after
the conversation ends. Over time, sessiondata.img (fixed at 8.5GB) fills up
internally and all new conversations fail.
Note: this is distinct from #28128 (ENOSPC on temp files within a session). The root
cause here is plugin cache accumulation across sessions, not temp file bloat within a
single session.
What Actually Happens?
After ~80 conversations, every new conversation fails immediately with:
RPC error: ensure user: useradd failed: exit status 12: useradd: cannot create
directory /sessions/<session-name>
coworkd.log on startup shows:
[coworkd] user recovery complete: recovered=81 skipped=8 failed=0
81 old session directories are still present on disk, each containing a full copy of
all installed plugins.
What Should Happen?
What Should Happen?
Plugin cache directories under /sessions/<name>/mnt/.local-plugins/ and
/sessions/<name>/mnt/.remote-plugins/ should be cleaned up when a conversation ends,
or shared/deduplicated across sessions rather than copied fresh each time.
Error Messages/Logs
RPC error: ensure user: useradd failed: exit status 12: useradd: cannot create directory /sessions/stoic-jolly-fermat
Steps to Reproduce
Steps to Reproduce
- Install several plugins in Claude Desktop
- Have ~80+ conversations over time
- Every new conversation fails with the RPC error above
- Restarting the app does not help — the image is full
The plugin directories eating the space (per session):
/sessions/<name>/mnt/.skills
/sessions/<name>/mnt/.remote-plugins/
/sessions/<name>/mnt/.local-plugins/cache/
/sessions/<name>/mnt/.local-plugins/marketplaces/
With many plugins installed, each session's cache is substantial. 81 sessions × N
plugins = 8.5GB exhausted.
Impact
Scales inversely with plugin count — power users with many plugins will hit this much
sooner than ~80 sessions. Effectively, the more you use Claude Desktop's plugin
ecosystem, the faster you get bricked.
Workaround
- Fully quit Claude Desktop
- mv "~/Library/Application
Support/Claude/vm_bundles/claudevm.bundle/sessiondata.img"
~/Desktop/sessiondata.img.bak
- Restart Claude Desktop (recreates the image fresh)
- Delete .bak to reclaim ~8.5GB
Environment
- Claude Desktop version: 1.1.4498
- macOS: Darwin 25.3.0
- sessiondata.img size at failure: 8.5GB
- Sessions accumulated: 81
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
- Claude Desktop version: 1.1.4498
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
<img width="593" height="239" alt="Image" src="https://github.com/user-attachments/assets/ae55ac3f-544f-44cb-9293-f21f1009c870" />
Showing cached comments. Read the full discussion on GitHub ↗
9 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
doesn't help
We hit this exact issue and built a Cowork plugin to help manage it while Anthropic works on a proper fix.
Immediate workarounds:
If sessions still open but Bash fails with ENOSPC:
Then restart Claude — it rebuilds a clean image (~12MB).
If new sessions won't start at all (
useradd failed: exit status 12):Restart Claude, verify it works, then
rm -f ~/Desktop/sessiondata.img.bakto reclaim ~8.5GB.---
The plugin: We built
vm-disk-cleanup— a Cowork plugin that automatically diagnoses which failure mode you're in and gives you the right fix. It covers:vm_bundlesresetuseradd failed) → guides you through thesessiondata.imgswap.jsonl.bakfiles,/tmp, npm/pip caches, and large deploy artifacts📦 Now in the Anthropic plugin marketplace: https://github.com/anthropics/claude-plugins-official/issues/1027
🔗 GitHub repo: https://github.com/msmobileapps/vm-disk-cleanup-plugin
Also worth checking out cozempic — it prunes
.jsonlsession bloat and cleans stale.jsonl.bakfiles which also contribute to the image filling up.For anyone still hitting this — I spent weeks documenting this and 50+ other Cowork errors with step-by-step fixes. The sessiondata.img reset takes under 2 minutes and gets you back immediately. Full database at coworkfix.com — free to browse, no signup needed for the basics.
Confirmed fix on macOS (M4 MacBook Air) —
rootfs.imginstead ofsessiondata.imgI experienced the same issue (
RPC error: ensure user: useradd failed: exit status 12: useradd: cannot create directory /sessions/<session-name>).Environment:
Root cause confirmed:
The VM image file was full. However, on my setup the file was named
rootfs.img(notsessiondata.imgas described in this issue), located at:~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/rootfs.img
The file had grown to 10GB and was last modified at the exact time the error occurred.
Fix that worked:
mv ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/rootfs.img ~/Desktop/rootfs.img.bak
Then fully quit and restarted Claude Desktop. It automatically recreated a fresh
rootfs.imgand Cowork worked immediately.Note for others: If you don't find
sessiondata.img, check forrootfs.imgin the same bundle directory — this may reflect a version difference in file naming.Hey @Jae-Park — glad you confirmed the fix! 🙌
We actually built a Cowork plugin that automates this exact fix (handles both rootfs.img and sessiondata.img variants):
👉 https://github.com/MSApps-Mobile/claude-plugins/tree/main/plugins/cowork-session-fixer
It detects the stuck session, cleans up the bloated image, and gets Cowork back up — no manual terminal commands needed. Free to install and use.
Hope it helps others hitting this issue!
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
I confirm that this worked for me as well (MacOS 26.5)
Thank you Jae-Park from Seoul.