[BUG] Cowork (Windows): caches fill sessiondata.vhdx; env-based caches can't be self-fixed & orphaned session dirs never cleaned

Resolved 💬 1 comment Opened May 27, 2026 by bbdiskoverdata Closed May 27, 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?

Summary
On Cowork (Claude Desktop), the persistent session disk (sessiondata.vhdx) fills over time with package-manager caches and orphaned session directories until sessions break with ENOSPC. Investigated live from inside the VM on a Windows host (2026-05-27). This adds a Windows data point and a shell-environment analysis explaining why users cannot mitigate the cache half themselves.

Environment

  • Host: Windows (virtiofs-backed VM); guest Ubuntu; session user uid 1002.
  • Two disks: /dev/sda1 -> / (OS image, 78% used at check time); /dev/sdc -> /sessions (the persistent session disk = sessiondata.vhdx).
  • $HOME = /sessions/<random-name>, created per session and seeded only from /etc/skel (.bashrc/.profile/.bash_logout).

Findings

  1. Orphaned session homes accumulate. A previous session's home (/sessions/wizardly-epic-volta) was still present alongside the active one. The coworkd binary contains the string "[process] removing session directory %s", so teardown cleanup is intended, but orphans clearly survive non-graceful exits.
  2. Users cannot fix the cache half from inside a session. The session user is uid 1002 with sudo disabled (no-new-privileges); /etc, /etc/skel, /opt, /usr/local/etc are read-only to it. The only writable persistent location is $HOME, which is regenerated under a new random name every session.
  3. Tool commands run in non-login, non-interactive shells spawned by coworkd (SHLVL=0, login_shell off, BASH_ENV empty). So ~/.bashrc, ~/.profile, /etc/profile.d/*, /etc/environment, and environment.d are never sourced for tool commands. (Proof: vars defined in /etc/environment, e.g. IS_SANDBOX/VM_IMAGE_BUILD, are absent from the actual process env.) The environment is injected directly by coworkd (HOME, USER, PATH, TMPDIR=/sessions/<name>/tmp, ...).
  4. The trap: pip/uv/npm honor config files (pip.conf/uv.toml/.npmrc) regardless of shell, so they're fixable via base-image config. But Hugging Face and Playwright have NO config file — their cache location can only be set by an environment variable, and the only thing that sets env for tool commands is coworkd. So there is no user-applicable fix for HF/Playwright today.

With nothing overridden, every cache defaults to $HOME on the session disk: pip -> ~/.cache/pip, uv -> ~/.cache/uv, npm -> ~/.npm, HF -> ~/.cache/huggingface, Playwright -> ~/.cache/ms-playwright (XDG_CACHE_HOME unset).

What Should Happen?

Smallest-first fixes:

  1. Inject cache-control vars into the per-session environment coworkd already builds (next to TMPDIR). This is the only way to handle HF/Playwright:

PIP_NO_CACHE_DIR=1
UV_NO_CACHE=1
npm_config_cache=$TMPDIR/npm-cache
HF_HOME=$TMPDIR/hf
PLAYWRIGHT_BROWSERS_PATH=$TMPDIR/ms-playwright
Scoping relocatable caches under the session TMPDIR keeps them on the roomy session volume and lets them be removed with the session.

  1. Make session-directory cleanup robust to non-graceful exit (crash/kill/ENOSPC), or sweep orphans on startup.
  1. Ship default cache config in the base image so pip/uv/npm are safe even without env changes: /etc/pip.conf (no-cache-dir = true), /etc/uv/uv.toml (no-cache = true), a cache=${TMPDIR}/npm-cache line in /etc/npmrc, and the same files under /etc/skel.
  1. Trim the base image, warn on high disk usage before the catch-22 (the disk fills silently, then df/du themselves can't run), and add a self-service reset in Desktop settings.

Error Messages/Logs

Representative failure when the disk is exhausted (as reported across the issue cluster):
  ENOSPC: no space left on device, mkdir '/sessions/<session-id>/tmp/claude-XXXX'

Disk split observed live in-VM:
  /dev/sda1   9.6G  7.4G  2.2G  78% /
  /dev/sdc    9.8G   96M  9.2G   2% /sessions   <- caches + per-session homes land here

Steps to Reproduce

  1. Use Cowork over many sessions, running pip/uv/npm/huggingface/playwright in the sandbox.
  2. Each session caches under $HOME on the /sessions disk; old session homes are not cleaned up on non-graceful exit.
  3. Over time /sessions (sessiondata.vhdx) fills; eventually new sessions fail with ENOSPC creating /tmp, bricking the Bash tool.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.9255.2 (1dc8f7) 2026-05-27T01:57:20.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Related (please link with area:cowork):

  • #30751 — Plugin cache never cleaned per session (CLOSED stale ~2026-05-24, unresolved; its bot asked filers to open a new issue)
  • #37860 — Root partition 86% full on fresh image (consolidated; labeled duplicate)
  • #37617 — Root disk too small for real projects (open)
  • #34602 — ENOSPC stuck at 75% on Windows 10 (closest Windows precedent)
  • #60029 — Recent ENOSPC, but a separate account-stuck-allocation case
  • #29448 / #37581 / #28128 — related ENOSPC reports
  • claude-plugins-official #1027 — community vm-disk-cleanup plugin (recovery, not prevention)

This report's angle (env injection + base-image config defaults + Windows cache growth) is not covered by the above.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗