Cowork workspace disk ships with ~6GB of unused system files, leaving <2GB usable space on a 9.7GB disk

Status Fixed / completed

Maintainer reply None cached

Activity 4 comments · opened Mar 29, 2026 · closed Mar 29, 2026

Summary

The Cowork workspace VM ships with a 9.7GB virtual disk, but approximately 7.6GB is pre-filled with system files that serve no purpose in a sandboxed dev environment. Users are left with less than 2GB of usable working space, and cannot clean it because sessions run without sudo access.

Disk breakdown

| Path | Size | Needed? |
|------|------|---------|
| /snap (LXD 727M, core20 391M, snapd 277M) | ~1.4GB | No |
| /var/lib/snapd | ~551MB | No |
| /usr/lib/firmware (hardware firmware blobs) | ~1.2GB | No — VM has no real hardware |
| /usr/lib/modules (kernel modules) | ~591MB | Partially |
| /usr/local/lib/python3.10 | ~572MB | Maybe |
| /usr/lib/libreoffice | ~302MB | No — dev workspace |
| /var/lib/apt (package cache) | ~283MB | No |
| /usr/local/lib/node_modules_global | ~186MB | Maybe |
| /var/log/journal | ~137MB | No |

Why users can't self-serve

Sessions run as a non-root user with no sudo. All the large system directories are root-owned. The only user-level cleanup available is ~52MB of npm cache — not meaningful.

Impact

Any project that installs dependencies (Node, Python, etc.) hits the wall almost immediately. The "workspace disk nearly full" warning appears with normal dev usage.

Suggested fixes

Slim the base image — remove firmware blobs, snap packages, LibreOffice. These have no place in a sandboxed dev VM.
Increase default disk size — 10GB is too small even with a clean image.
Give users a resize option — either via UI or by documenting the truncate + resize2fs approach.
Or give users sudo — so they can clean their own workspace.

Workaround (manual, outside the VM)

# 1. Quit Claude Code
# 2. Extend the disk image:
truncate -s 30G ~/Library/Application\ Support/Claude/vm_bundles/claudevm.bundle/sessiondata.img
# 3. Restart Claude Code, then inside Cowork:
lsblk                  # find device name (e.g. /dev/vdb)
resize2fs /dev/vdb     # expand filesystem to fill new space

View original on GitHub ↗

4 Comments

mustafa · 6 months ago

Update after further investigation — corrected architecture:

The VM actually has two separate disks, not one:

| Device | Size | Mount | Purpose |
|--------|------|-------|---------|
| nvme0n1p1 | 9.6GB (80% used) | / | Base OS image — bloated with firmware/snaps/LibreOffice |
| nvme1n1 | 10GB | /sessions | User working space — clean, separate |

Key correction: The root partition bloat (~7.6GB) does NOT directly steal from user working space — /sessions is a separate disk with its own 10GB. So users get the full 10GB for actual work, not 2GB as initially thought.

What actually causes the "workspace full" warning: The /sessions disk fills up with real project files (node_modules, build artifacts, installed packages). 10GB runs out quickly on any non-trivial project.

Why the resize attempt doesn't work from inside: Sessions run with no new privileges — no root, no sudo. resize2fs, growpart, and removing root-owned system packages are all blocked. The VM restart is also controlled externally.

Revised asks:

Increase the /sessions disk from 10GB to at least 20-30GB
Slim the root image anyway — 80% used on the OS disk is a ticking clock for stability
Consider giving users a way to expand their session disk via the UI

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code