## Summary My Cowork sandbox has failed to provision at least 5 times in the last week (22, 25, 26, 27, 28 Jul 2026), each time with: ``` RPC error: ensure user: useradd failed: exit status 12: useradd: cannot create directory /sessions/ ``` or the disk-full variant: ``` useradd: No space left on device ``` Each failure kills that day's scheduled work with no bash access and no error surfaced until I go looking for it. ## Not a new bug This matches the failure mode already described i

Cowork sandbox recurring failure — useradd exit 12 / no space left on device (5 recurrences in a week, prior fix didn't hold)

Status Open

Maintainer reply None cached

Activity 6 comments · opened Jul 28, 2026

Summary

My Cowork sandbox has failed to provision at least 5 times in the last week (22, 25, 26, 27, 28 Jul 2026), each time with:

RPC error: ensure user: useradd failed: exit status 12: useradd: cannot create directory /sessions/<name>

or the disk-full variant:

useradd: No space left on device

Each failure kills that day's scheduled work with no bash access and no error surfaced until I go looking for it.

Not a new bug

This matches the failure mode already described in these issues — all closed as stale/duplicate by the bot, not by a maintainer confirming a fix shipped:

#36465
#43850
#56439
#59856

Per #59856's diagnosis: the sandbox's ephemeral disks (~10GB each) fill because per-session /sessions/<name>/ directories are never garbage-collected, plus unbounded caches (Playwright Chromium downloads, systemd journal, npm cache). Once full, useradd can't create the next session's home directory, so no new session — including scheduled tasks — can start. The sandbox user has no sudo and can't clean any of it up itself; only a platform-side fix (GC old session dirs, cap the caches, or surface the failure with a recovery path) resolves it.

Timeline

I raised this internally on 26 Jul with a specific ask for a root-cause fix (not another workaround). It recurred again on 27 and 28 Jul — so whatever mitigation was attempted didn't hold, or the underlying GC gap in the platform is still there.

Ask

Please either:
(a) point to the actual fix/owner for the four issues above, or
(b) treat this as still open and share what's being done — it's now blocking real day-to-day work on a ~weekly cadence.

Happy to provide session IDs, timestamps, or logs on request.

View original on GitHub ↗

4 Comments

KennethMackay · 1 month ago

Second independent report of this, on Claude Cowork (desktop, Windows 11).

My sandbox worked normally on 29 Jul 2026 and has failed to provision continuously
since 30 Jul, with the identical error on every attempt:

RPC error -1: ensure user: useradd failed: exit status 12:
useradd: cannot create directory /sessions/<name>

A full Windows reboot and an app restart both changed nothing, which is expected
given /sessions is server-side, but it does rule out the two obvious client-side
remedies. Unlike the intermittent pattern above, mine has not recovered between days.

It is inode exhaustion, not byte exhaustion

This may refine the diagnosis in #59856. Measured on 29 Jul, while the sandbox
still booted:

| Measurement | Value | Method |
|---|---|---|
| Inode table on /sessions | 655,360 total, ~654,600 used, ~750 free | os.statvfs('/sessions') |
| Free disk space at that moment | 3.4 GB free | df -h |
| Session directories at volume root | 814 | os.listdir('/sessions') |
| Readable by my session | 1 of 814 (my own) | PermissionError on the rest |
| My own session's footprint | 173 inodes | find /sessions/<id> -xdev \| wc -l |

So the volume ran out of inodes with gigabytes of space still free. That is
consistent with the never-garbage-collected diagnosis rather than contradicting it —
accumulated session trees full of small files exhaust the inode table long before the
bytes — but it means "the 10GB ephemeral disk fills" is not the whole mechanism, and a
fix that only caps cache size would not address it.

The 173-inode figure also bounds what any user can do about it: my own session, after
an unusually heavy day, accounted for about 0.03% of what was consumed. The rest sits
in other sessions' trees, which are unreadable and unreclaimable from inside a session.

The free-inode counter is not a usable warning signal

It reads zero continuously while most writes still succeed. A full 36-case test suite
passed with the counter pinned at 0 free inodes, sampled before and after each case.
So there is no threshold a user could watch to get ahead of this.

Higher-severity consequence: `tempfile` silently relocates to `/tmp`

This one is worth attention beyond the availability impact. Before the sandbox
fails to start, it enters a state where /sessions cannot take a write — and in that
state tempfile.gettempdir() silently returns /tmp instead of the session-local
directory. Measured in both directions on 29 Jul: at 0 free inodes a direct write to
$TMPDIR failed [Errno 28] and gettempdir() returned /tmp; after freeing 64
inodes, the next call returned the session-local path again.

This is ordinary CPython behaviour — _get_default_tempdir() tests each candidate in
[TMPDIR, /tmp, /var/tmp, /usr/tmp] by creating a file and falls through on failure —
so a correctly exported TMPDIR provides no protection. There is no exception, no
warning, and no change in return type; only the path changes.

At time of measurement /tmp in the sandbox was drwxrwxrwt, owner nobody, with
2,369 entries, 8 of them owned by other users. So once the fallback happens, any
fixed-name temp path becomes a live cross-session collision hazard, and code that
believes it is writing to a session-private directory is writing to a shared one.

That makes this a correctness issue and not only an availability one: it changes where
user data is written, silently, before anything visibly breaks.

Ask

Adding to the ask above — please also consider whether the failure can be surfaced
earlier than total provisioning failure. A message distinguishing inode exhaustion
from disk exhaustion would have saved considerable diagnosis time, and the silent
/tmp fallback means the degraded state is currently invisible to the user until it
is total.

Happy to provide session IDs, timestamps or the full measurement transcript.

twortley · 19 days ago

Independent confirmation, 11 Aug 2026, different account, Windows (Claude desktop, MSIX). Two weeks on from your report and the behaviour is unchanged, so adding evidence to keep this from going stale.

Live capture from inside the sandbox

Filesystem       Size  Used Avail Use% Mounted on
/dev/sda1        9.6G  5.8G  3.8G  61% /
/dev/sdc         9.8G  9.3G     0 100% /sessions

Zero bytes available on /sessions. dd of 20MB into my own session dir returns success but writes nothing:

0+0 records out
0 bytes copied, 0.000284267 s, 0.0 kB/s

32 session directories going back to 3 July 2026, all nobody:nogroup. Your point in the original report — that the sandbox user has no sudo and can't clean any of it up — holds exactly: unprivileged uid, sudo blocked, every stale directory unreadable. du from inside reports 4.5M total because it can't traverse them; df sees the real 9.3G.

Also confirming this is a byte-exhaustion problem specifically, not inode exhaustion — df -i /sessions shows 2% inodes used. And it is not the / filesystem: root still has 3.8G free, with /var/log/journal at 185M and /var/cache/apt at 133M, both well short of the levels reported in #59856. On this instance the leak is entirely in un-GC'd /sessions/<name>/.

A narrower recovery on Windows than the one in circulation

On Windows the two sandbox disks are separate local VHDX files in ...\Claude\vm_bundles\claudevm.bundle\:

rootfs (~9.8 GB) → mounts as /, 61% used, fine
sessiondata (~9.6 GB) → mounts as /sessions, the one at 100%

So the recovery is quit Claude Desktop → delete sessiondata only → reopen. No reboot and no VM re-download. sessiondata has no .origin file (unlike rootfs), so it's locally generated and just regenerates; connected folders are bind mounts to the real Windows filesystem, so nothing of the user's lives on it.

Cheaper than deleting the whole bundle, but it is still a workaround on the same treadmill you describe — it buys weeks, then refills, because the GC gap is untouched.

Supporting your ask

Your question (a)/(b) is still the right one and still unanswered. #59856 was closed as duplicate in May without a maintainer confirming a fix shipped; #60029 and #72874 are both still open with the same root cause in different clothing. That's four issues describing one un-GC'd directory and no identified owner. A pointer to the tracking issue would be worth a lot here.

Duncan1947 · 19 days ago

I am not using a windows machine

Duncan Wilde
Managing Director
DJ Wilde Consulting Limited
Mob : 07775503025

On Tue, 11 Aug 2026 at 7:13 pm, Tim Wortley @.***>
wrote:

twortley left a comment (anthropics/claude-code#81879) <https://github.com/anthropics/claude-code/issues/81879#issuecomment-5257063619> Independent confirmation, 11 Aug 2026, different account, Windows (Claude desktop, MSIX). Two weeks on from your report and the behaviour is unchanged, so adding evidence to keep this from going stale. Live capture from inside the sandbox Filesystem Size Used Avail Use% Mounted on /dev/sda1 9.6G 5.8G 3.8G 61% / /dev/sdc 9.8G 9.3G 0 100% /sessions Zero bytes available on /sessions. dd of 20MB into my own session dir returns success but writes nothing: 0+0 records out 0 bytes copied, 0.000284267 s, 0.0 kB/s 32 session directories going back to 3 July 2026, all nobody:nogroup. Your point in the original report — that the sandbox user has no sudo and can't clean any of it up — holds exactly: unprivileged uid, sudo blocked, every stale directory unreadable. du from inside reports 4.5M total because it can't traverse them; df sees the real 9.3G. Also confirming this is a byte-exhaustion problem specifically, not inode exhaustion — df -i /sessions shows 2% inodes used. And it is not the / filesystem: root still has 3.8G free, with /var/log/journal at 185M and /var/cache/apt at 133M, both well short of the levels reported in #59856 <https://github.com/anthropics/claude-code/issues/59856>. On this instance the leak is entirely in un-GC'd /sessions/<name>/. A narrower recovery on Windows than the one in circulation On Windows the two sandbox disks are separate local VHDX files in ...\Claude\vm_bundles\claudevm.bundle\: - rootfs (~9.8 GB) → mounts as /, 61% used, fine - sessiondata (~9.6 GB) → mounts as /sessions, the one at 100% So the recovery is quit Claude Desktop → delete sessiondata only → reopen. No reboot and no VM re-download. sessiondata has no .origin file (unlike rootfs), so it's locally generated and just regenerates; connected folders are bind mounts to the real Windows filesystem, so nothing of the user's lives on it. Cheaper than deleting the whole bundle, but it is still a workaround on the same treadmill you describe — it buys weeks, then refills, because the GC gap is untouched. Supporting your ask Your question (a)/(b) is still the right one and still unanswered. #59856 <https://github.com/anthropics/claude-code/issues/59856> was closed as duplicate in May without a maintainer confirming a fix shipped; #60029 <https://github.com/anthropics/claude-code/issues/60029> and #72874 <https://github.com/anthropics/claude-code/issues/72874> are both still open with the same root cause in different clothing. That's four issues describing one un-GC'd directory and no identified owner. A pointer to the tracking issue would be worth a lot here. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/81879?email_source=notifications&email_token=B73ZTDA2BBKOY4H7KIHHPFT5JNO5JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVG4YDMMZWGE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5257063619>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B73ZTDBRX43KX66H37AG3PD5JNO5JAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIOJZGYYDQNZTGQZ2C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B73ZTDE7Z3GBHNVMAWQYCUD5JNO5JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVG4YDMMZWGE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/B73ZTDBFOF5HHGOV4AVFE4D5JNO5JA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRVG4YDMMZWGE42M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: @.***>

KennethMackay · 18 days ago

I received the following from Anthropic's support:

That's the Cowork VM hitting an internal limit. It's the VM's own disk/state, not your computer's.
The reset path: in Claude Desktop, Help > Troubleshooting > Delete Cowork VM Bundle. This wipes the VM and pulls a fresh one on next launch. You'll lose the current Cowork session context, but your Claude conversations and account are untouched.
Newer Desktop versions handle this more gracefully, so Help > Check for Updates is worth trying first if you haven't recently. The Cowork guide at https://support.claude.com/en/articles/13345190 covers what the VM bundle contains.

I haven't tried yet because I am working OK using Claude on a different PC.

Good luck, and let us know how you get on.

Showing cached comments. Read the full discussion on GitHub ↗