[BUG] Cowork sandbox: /sessions never garbage-collected — 1,634 dirs over 4 months filled the disk; all scheduled tasks fail at `useradd` exit 12

[eolinger]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

The Cowork sandbox never garbage-collects /sessions// directories. After ~4 months of scheduled-task runs they filled the 9.8G volume, and every new session — every scheduled task — now fails before executing a single instruction.

This is filed again despite prior reports because those were closed without a fix and the failure mode is worse than "a task didn't run": it is silently invisible. Six independent agent lanes each reported their own local symptom ("no GitHub access this run") and none of them could see the shared cause, because diagnosing it requires a shell and the shell is what is broken.

Prior reports, all still unfixed: #59856 (closed as duplicate), #48691 (closed as not planned, labelled area:cowork/bug), #30751, #44622, #44877, #55246, #37581.

Error signature

Identical on every run, only the generated name varying:

ensure user: useradd failed: exit status 12:
useradd: cannot create directory /sessions/

useradd exit 12 is "cannot create home directory" — what a full filesystem produces.

Measurements

Taken from an interactive session that survived only because it was provisioned before the volume filled:

$ df -h /sessions
Filesystem Size Used Avail Use% Mounted on
/dev/nvme1n1 9.8G 9.8G 0 100% /sessions

$ df -i /sessions # inodes are NOT the constraint
/dev/nvme1n1 655360 110821 544539 17% /sessions

$ ls /sessions | wc -l
1634

$ ls -ld /sessions/gifted-admiring-bell
drwxr-x--- 4 nobody nogroup 4096 2026-05-09 /sessions/gifted-admiring-bell

$ ls -ld /sessions
drwxr-xr-x 1636 nobody nogroup 69632 /sessions # not writable by a session user

$ sudo -n true
sudo: /etc/sudo.conf is owned by uid 65534, should be 0

Oldest surviving directory: 2026-05-09 — four months, 1,634 directories, zero reclaimed. No deleted-but-open files, so this is accumulation and not a held-handle leak.

A diagnostic trap worth fixing in its own right: du -sx /sessions reports 6.8M, because the other 1,633 directories are unreadable to any single session user and du skips them silently. Anyone debugging from inside sees a nearly empty volume that df says is 100% full. The space is real and invisible.

No recovery is possible from inside the sandbox

/sessions is drwxr-xr-x nobody:nogroup, so a session user cannot even unlink an entry, let alone descend into one. Every session directory is drwxr-x--- nobody:nogroup. sudo is blocked. There is nothing an agent or a user can do from within.

Quitting and relaunching the desktop app does NOT fix it — verified

We tried this first. Afterwards the sandbox returned with the same uid and the same session name, and /sessions still read 9.8G / 0 avail / 100%. The VM bundle is reused, not reprovisioned. #59856 reports the same thing.

What actually fixed it

Moving the VM bundle aside on the host, which is undocumented and not discoverable from any error message:

bash

Quit Claude Desktop (Cmd+Q) first

mv ~/Library/Application\ Support/Claude/vm_bundles
~/Library/Application\ Support/Claude/vm_bundles.BROKEN

Relaunch — the VM rebuilds

Result, immediately after:

/dev/nvme1n1 9.8G 1.2M 9.3G 1% /sessions (was 100%)
/dev/nvme0n1p1 9.6G 4.7G 4.9G 49% / (was 77%)
$ ls /sessions | wc -l
4 (was 1634)

Note the root filesystem reclaimed 2.6G as well — so the leak is not confined to /sessions.

Impact

Six scheduled agent lanes plus a 30-minute orchestration sweep, all failing at provisioning for ~2.5 hours before a human diagnosed it, and it would have continued indefinitely. For anyone relying on scheduled tasks for unattended work, this is a silent total outage with no surfaced cause and no documented recovery.

What Should Happen?

1. Garbage-collect /sessions// on sandbox boot — anything older than N days with no live process. This is the actual bug; everything else below is mitigation.
2. Surface the provisioning failure to the user. A scheduled task that cannot provision should say that, not fail into whatever local symptom the task notices. Six lanes each reported a different wrong cause.
3. Add a "Reset sandbox storage" control in Cowork settings. Today the only working remedy is an undocumented vm_bundles path found by searching GitHub issues.
4. Bound the caches — share plugin/browser caches across sessions rather than copying per session ([BUG] Cowork Plugin cache never cleaned up per session, causing sessiondata.img to fill up and all new conversations to fail #30751).
5. Make the disk state legible from inside. Given du cannot see other sessions' directories, ship a readable summary or let df be interpretable — otherwise every future diagnosis hits the same 6.8M-vs-9.8G contradiction.

Error Messages/Logs

ensure user: useradd failed: exit status 12: useradd: cannot create directory /sessions/amazing-quirky-cray
ensure user: useradd failed: exit status 12: useradd: cannot create directory /sessions/charming-adoring-albattani
ensure user: useradd failed: exit status 12: useradd: cannot create directory /sessions/focused-adoring-allen
ensure user: useradd failed: exit status 12: useradd: cannot create directory /sessions/gifted-awesome-gates

Steps to Reproduce

1. Run Cowork on macOS with several scheduled tasks on 15–60 minute cadences.
2. Leave it for weeks. Watch ls /sessions | wc -l climb monotonically; nothing is ever removed.
3. When the ~9.8G /sessions volume fills, every new session fails at useradd with exit status 12.
4. Note that quitting and relaunching the app does not clear it.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.186 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Usage profile: 6 scheduled agent lanes plus a 30-minute sweep, running continuously since ~2026-05. That cadence reaches the limit in about four months.

[alflanagan]

How do we get this bumped in priority and keep it from being tagged as "stale" or autoclosed? The only workaround seems to be removing the folder ~/Library/Application Support/Claude/vm_bundles. Users should not have to touch those directories, and it appears the fix is not officially documented.