[BUG] Cowork VM session disk fills within hours for scheduled task users — no cleanup, no resize path

Resolved 💬 2 comments Opened Apr 7, 2026 by Corvanadasha Closed Apr 10, 2026

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?

The Cowork VM's /sessions partition is hardcoded at ~10GB with no auto-cleanup mechanism. For users running multiple scheduled tasks, this disk fills up within hours, requiring a full manual reset (delete sessiondata.vhdx + restart PC) to recover. This makes Cowork's scheduled task feature impractical for any meaningful automation workload.

Environment:

  • OS: Windows 11 Pro
  • Claude Desktop: Latest (April 2026)
  • Plugins installed: ~15 (Shopify, ReAmaze, IMAP, Motion, Ahrefs, DataForSEO, Firecrawl, Klaviyo, Gmail, Google Calendar, etc.)
  • Scheduled tasks: ~30 active (mix of hourly, daily, and weekly)

What happens:

  1. Each scheduled task run creates a new session directory under /sessions/ inside the VM
  2. Each session caches all installed plugins independently
  3. Session directories are never cleaned up after the task completes
  4. With ~25-37 task runs per day and ~15 plugins, the 10GB /sessions disk fills within hours
  5. Once full, all new sessions fail with ENOSPC errors
  6. The only recovery is quitting Claude, deleting sessiondata.vhdx from the host, and restarting the PC

What I've tried (none of these work):

| Approach | Result |
|----------|--------|
| Resize-VHD to 30GB + PC restart | VM still shows 9.8GB — filesystem is created at fixed size, ignores extra VHDX space |
| growpart / resize2fs from inside VM | No root access (sandbox), no partition table (raw disk mount), no write access to sysfs for SCSI rescan |
| Cleanup task to delete stale sessions | Each session runs as its own sandboxed user — cannot delete other sessions' directories |
| Cleanup task to clear root filesystem caches | No sudo/root access from inside sandbox |
| PowerShell script to stop cowork-svc + delete VHDX + restart Claude (no PC restart) | Fails with "VM service not running" — full PC restart is the only way to recover |

The root filesystem also fills up:
The root disk (/dev/sda1, also ~10GB) is at 85% from accumulated pip packages (718MB in /usr/local/lib/python3.10/dist-packages/), journal logs (321MB), apt cache (128MB), and rotated syslogs (58MB). These persist across all sessions and cannot be cleaned from inside the sandbox.

Impact:
This is a showstopper for using Cowork as an automation platform. The scheduled task feature is one of Cowork's most compelling capabilities, but the disk management makes it unusable for anything beyond a handful of infrequent tasks.

Related issues: #30751, #37581, #24207, #22543

What Should Happen?

Any of these would resolve the issue:

  1. Auto-cleanup of completed session directories — when a scheduled task finishes, its session data should be purged (or at least the plugin cache)
  2. Shared plugin cache — instead of each session independently caching all plugins, use a single shared cache
  3. Auto-expand filesystem on boot — if a user resizes the VHDX, detect and expand the partition/filesystem on startup
  4. Configurable disk size — allow users to set the session disk size via config
  5. Root filesystem cleanup on boot — vacuum journal logs, clear apt cache, purge pip cache on VM startup
  6. Graceful degradation — instead of hard-failing with ENOSPC, alert the user and auto-clean old sessions before the disk is completely full

Error Messages/Logs

Steps to Reproduce

  1. Install Claude Desktop on Windows 11 Pro with Cowork mode enabled
  2. Install 10+ plugins (Shopify, ReAmaze, IMAP, Motion, Firecrawl, etc.)
  3. Create 20+ scheduled tasks (mix of hourly, daily, and weekly)
  4. Leave Claude Desktop running for several hours
  5. Run df -h /sessions from within a Cowork session — disk fills to 100% within hours
  6. All new sessions and bash commands fail with ENOSPC errors
  7. Only recovery: quit Claude, delete sessiondata.vhdx from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle, restart PC

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Latest (April 2026)

Claude Code Version

Claude Desktop (Cowork mode)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗