What's Actually Happening When ENOSPC Hits
One morning a scheduled task I run had gone silent halfway through. The log showed bash had simply stopped answering commands, and just before that, four short letters: ENOSPC. This was April 15, 2026.
ENOSPC stands for "No space left on device" — the filesystem has zero writable blocks remaining. In my case the direct culprit was an npm install buried in the pipeline. While updating four technical blogs in parallel, the node_modules folders across several repositories had quietly eaten the VM's ~10GB disk, and on one particular run they finally crossed the line.
Error: ENOSPC: no space left on device, write
at Object.writeFileSync (fs.js:1234:15)
at /workspace/debug.log
What makes this error nasty is that the instant it appears, everything freezes. You can't write logs, you can't save files, and git commit won't go through. Storage accumulates silently for a long time, then becomes a wall in a single moment — disk problems always arrive in that shape.
Why the Disk Fills Up — Three Usual Suspects
In the order I actually hit them:
1. Build artifacts and package caches piling up
This was the heart of my incident. A single repo's node_modules can exceed 500MB, and build caches like .next regenerate repeatedly without ever being cleared. Move between several projects and it stacks up fast.
2. Runaway debug logging
A stray print inside a loop reaches gigabytes after a few million iterations. A print inside while True: fills disk far faster than you'd expect.
3. Leftover temp files
/tmp holds onto files from previous runs. Each one is tiny, but with frequent runs it adds up.
First, Find Where the Space Went
Before recovering, figure out what's swollen. Deleting on a hunch sweeps away things you needed.
df -h
du -sh ~/* 2>/dev/null | sort -rh | head -10If df -h shows usage above 90%, you're critical. If node_modules, .next, or huge .log files sit at the top of du, that's your culprit. In my case, other sites' working repositories were occupying the top slots.
On-the-Spot Recovery Steps
Step 1: Shut down and restart Close Cowork or Claude Code completely, wait a few seconds, and reopen. Memory-resident temp files get released, and sometimes that alone is enough.
Step 2: Delete what's actually eating the space
# Find files over 1GB
find ~ -type f -size +1G 2>/dev/null
# Sweep old logs and build caches
find ~ -name "*.log" -mtime +30 -delete 2>/dev/null
find ~ -type d -name ".next" -exec rm -rf {} + 2>/dev/nullOne caution here: don't casually re-run npm install at this stage. If a package cache is what filled the disk, reinstalling just pours fuel on the fire. That's the exact mistake I made the first time.
Step 3: Clear caches in bulk
npm cache clean --force
rm -rf ~/.cowork/cacheStep 4: When it still won't budge Use the menu → Cowork → Reset App Data to reset the app-side data (your project files stay protected). If even that doesn't resolve it, contact Anthropic Support (support@anthropic.com) with your usage percentage, the error message, and the timestamp.
Designing So It Never Jams Again — Three Things I Added to My Pipeline
Building structural safeguards beat ad-hoc cleanup by a wide margin over time. Both of my grandfathers were miyadaiku — traditional shrine carpenters — and growing up watching them maintain what they'd built so it would last for decades, I suppose I'm wired to put effort into "don't let it accumulate" design.
Design 1: I removed npm install from the pipeline entirely
To merely add an article, you only need to fetch the repository, write the MDX, and push. The build can be left to Cloudflare's CI, so there was actually no need to create node_modules on the VM at all. That single change erased the biggest source of disk pressure. The most effective fix being "just don't do it" was a little ironic.
Design 2: Auto-free space when it drops below a threshold Before working, I measure free space, and if it's under 500MB I automatically reclaim it in order: other sites' working repos → npm build cache → global cache.
FREE_MB=$(df ~ --output=avail -m 2>/dev/null | tail -1 | tr -d ' ')
if [ "${FREE_MB:-0}" -lt 500 ]; then
for OTHER in ~/repos/*; do
[ "$OTHER" != "$WORK" ] && rm -rf "$OTHER" 2>/dev/null
done
npm cache clean --force 2>/dev/null
fiDesign 3: Build an escape route for unwritable locations
When I hit an environment where /tmp was owned by another user and not writable, I made the workflow fall back to $HOME/repos. It's not ENOSPC itself, but it prevents getting doubly stuck — running out of writable space mid-recovery.
Your Next Move
Run df -h once in your current environment right now. If usage is past 50%, glance at the top of du -sh ~/* | sort -rh | head, and delete one stale node_modules or old log. That alone sharply cuts the odds of work freezing on a busy day. Ever since I made typing that one line a Monday-morning habit, ENOSPC redos have all but disappeared for me.