claude-code - 💡(How to fix) Fix Cowork (local-agent-mode) sandbox: per-session disk leak fills ephemeral disks; new sandboxes fail with `useradd: No space left on device`

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 (Claude desktop app's local-agent-mode) accumulates per-session state across runs with no garbage collection. After enough sessions, the sandbox's two ~10GB ephemeral disks fill to 100% and new sandbox provisioning fails inside useradd with No space left on device. Every subsequent session — including all scheduled tasks — fails silently from the user's perspective, with no surfaced error and no documented recovery path.

Related: #24207 (no disk space management for ~/.claude), #43645 (scheduled-task heartbeat creates hundreds of junk sessions). Filing this separately because the failure mode here is the sandbox itself refusing to boot a new user, which blocks the user from doing anything at all in Cowork mode until they take destructive action on their own machine.

Repro (organic, observed in production)

My Cowork sandbox has been running a daily scheduled task (Instacart price scanner) since 2026-03-06. Today (2026-05-16) the task failed for the third day in a row with:

bash failed on resume, create, and re-resume.
resume: RPC error: ensure user: useradd failed: exit status 1:
  useradd: /etc/passwd.99361: No space left on device
  useradd: cannot lock /etc/passwd; try again later.

Once I got the sandbox to boot, df confirmed both ephemeral disks were full:

Filesystem       Size  Used Avail Use% Mounted on
/dev/nvme0n1p1   9.6G  9.5G   56M 100% /
/dev/nvme1n1     9.8G  9.3G     0 100% /sessions

What's hogging space

On / (root fs):

• /var/tmp/.pw-browsers/ — 956MB (Playwright Chromium cache from prior scheduled runs)
• /var/log/journal/ — 769MB (unbounded systemd journal)
• /var/lib/snapd/ — 430MB
• /var/cache/apt + /var/lib/apt — ~420MB
• /var/tmp/npm-cache + /var/tmp/cf-deploy — ~333MB

On /sessions (sessions fs):

• 121 session directories owned by nobody:nogroup dating back to 2026-03-06, never removed. du from inside the current session can't read them (perms locked), but df says they collectively account for the 9.3G of used space. Today's session dir is only 5.8M; the rest is dead weight from past sessions.

Impact

1. Scheduled tasks fail silently. From the user's side it just looks like the task didn't run — no notification, no error in chat. They only notice because the expected output (in my case, an iMessage digest) doesn't arrive.
2. No recovery path the user can take from inside the sandbox. The sandbox user is unprivileged (uid=1121), sudo is blocked by no_new_privs, and all the bloated directories are owned by nobody:nogroup. Even with full investigation access, the sandbox user cannot delete a single byte of the cruft.
3. No documented reset. Quitting/relaunching the Claude desktop app doesn't reliably reprovision the sandbox storage. There's no UI control, no CLI command, and no documented directory to delete on the Mac to force a clean rebuild.

Suggested fixes

In rough order of impact:

1. GC old /sessions/<name>/ directories on sandbox boot. Anything older than N days (7? 30?) with no active process should be removable on next provision.
2. Share the Playwright cache across sessions instead of leaving each run's copy in /var/tmp/.pw-browsers/, or cap its size.
3. Bound /var/log/journal/ — SystemMaxUse=200M or similar in journald.conf for the sandbox image.
4. Add a "Reset sandbox storage" button in the Claude desktop app's Cowork settings, with a one-line description of what it does.
5. Surface the useradd: No space left on device error to the user instead of swallowing it. Right now the user just sees bash failed on resume, create, and re-resume with no diagnosis.

Environment

• macOS (Claude desktop app, Cowork mode / local-agent-mode)
• Sandbox image: Ubuntu 22 (per /etc/os-release from inside the sandbox)
• Sandbox user: unprivileged uid (1121), no_new_privs set
• Two ephemeral disks: /dev/nvme0n1p1 mounted at / (~10G), /dev/nvme1n1 mounted at /sessions (~10G)
• Mac-side connected folder is bindmounted in at /sessions/<name>/mnt/outputs and is NOT the source of the leak — the leak is internal to the sandbox image

Workaround I've applied

For my daily scheduled task, I've patched the task playbook to:

1. Pre-flight check df and abort with a useful iMessage instead of running blindly when either disk is >=95% full.
2. Make Playwright install actually idempotent — skip npx playwright install chromium when the cache exists, instead of re-downloading 956MB every run.
3. Best-effort cleanup of /tmp and npm cache at the end of each run.

This stretches the time between failures but doesn't fix the underlying GC issue.

What Should Happen?

Cowork sandbox should either (a) garbage-collect old /sessions/<name>/ directories and bounded caches so the ephemeral disks don't fill, or (b) surface the disk-full / useradd: No space left on device failure to the user in a recoverable way, with a clear path to reprovision the sandbox storage.

At minimum: scheduled tasks should not silently fail when the sandbox can't boot a new user. The user should see a notification in chat or via whatever channel they normally get task output through.

Error Messages/Logs

From the failed scheduled-task run on 2026-05-16:

bash failed on resume, create, and re-resume.
resume: RPC error: ensure user: useradd failed: exit status 1: useradd: /etc/passwd.99361: No space left on device
useradd: cannot lock /etc/passwd; try again later.
; create: RPC error: ensure user: useradd failed: exit status 1: useradd: /etc/passwd.99362: No space left on device
useradd: cannot lock /etc/passwd; try again later.

From inside the sandbox once it eventually booted:

$ df -h /
Filesystem       Size  Used Avail Use% Mounted on
/dev/nvme0n1p1   9.6G  9.5G   56M 100% /

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

$ ls /sessions | wc -l
121

$ ls -ld /sessions/admiring-compassionate-feynman
drwxr-x--- 6 nobody nogroup 4096 Mar  6 00:26 /sessions/admiring-compassionate-feynman

$ sudo -n true
sudo: /etc/sudo.conf is owned by uid 65534, should be 0
sudo: The "no new privileges" flag is set, which prevents sudo from running as root.

Steps to Reproduce

Not a single-action bug — it's a slow accumulation. Reproduction over time:

1. Use Cowork mode in the Claude desktop app (macOS) for several weeks. Run a scheduled task at least daily — e.g. anything that installs Playwright + Chromium, or anything that does substantial work in the sandbox per run.
2. After ~6 weeks of daily runs, observe that the sandbox's /sessions/ accumulates one directory per session (ls /sessions | wc -l will show 100+ after a couple months) and /var/tmp/.pw-browsers/, /var/log/journal/, etc. grow unbounded.
3. Eventually df -h / and df -h /sessions will show ~100% used on the sandbox's two ephemeral ~10GB disks.
4. The next attempt to start a sandbox session fails with useradd: /etc/passwd.NNNNN: No space left on device, and bash failed on resume, create, and re-resume. Scheduled tasks fail silently from this point on.

Faster repro for development: artificially fill the sandbox's / and /sessions to >99% (e.g. dd if=/dev/zero of=/tmp/fill bs=1M count=9500 may work depending on which fs /tmp lives on) and then try to start a new Cowork session. The useradd failure should reproduce immediately.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

N/A — this is a Claude desktop app / Cowork (local-agent-mode) bug, not Claude Code CLI. macOS desktop app, version visible in About menu. Sandbox image inside is Ubuntu 22.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response