[BUG] Cowork /sessions never garbage-collects session directories (2,328 stale dirs, disk at 100%, unrecoverable from sandbox)

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?

This is the Cowork desktop app, not the Claude Code CLI. There is no Cowork issue template, so I am using this one. The Claude Code version / terminal / platform fields below do not apply and I have filled them as honestly as I can.

This is the same bug as #61074, which was closed as not planned. I am re-filing because it has since got materially worse and the closure left the reporter, and now me, with no recovery path. #61074 reported 371 stale session directories on Windows in May. This machine now has 2,328.

The bug

The Cowork sandbox's /sessions volume creates one directory per session and never deletes one. On this machine it now holds 2,328 session directories and sits at 100% used, 0 bytes available.

Every directory except the current session's is owned by nobody:nogroup mode 0750. An unprivileged sandbox user cannot read or delete them, there is no sudo, and there is no reset command. The disk therefore cannot be recovered from inside the sandbox.

The oldest session directory is dated 2026-05-22, the same date as lost+found — i.e. nothing has ever been garbage-collected since the volume was created. Only 2 live fuse mounts exist across all 2,328 directories, so these are inert leftovers, not active sessions.

What it costs

• /sessions has been pinned at 100% since 2026-07-30, over a month.
• Scheduled tasks fail silently. No user-facing error of any kind. I only caught this because my task was built to write a durable log row even on failure. A task that cannot start reports nothing.
• Writes to $HOME now return 0 bytes. Interactive work is only still possible because /tmp lives on /, which is at 64%.
• Four separate automated jobs on this account have been blocked by it (package installs, CLI bootstrap, and others).

It is not the base image and not workspace size

I filed a support ticket for this in March that guessed the base OS image was too large. That was wrong, and I want to correct it publicly. / (/dev/sda1) is at 64% with 3.6 GB free. The entire 9.6 GB is dead session state on /dev/sdc. Reducing the mounted workspace folder does nothing.

The measurement trap

du is actively misleading on this volume:

$ du -x -d1 /sessions 2>/dev/null | head -1
9720    /sessions          # ~9.5 MB — looks perfectly healthy

That is du hitting "Permission denied" on 2,327 directories with stderr suppressed. df says 9.6 GB.

#61074 hit the same discrepancy (11 MB visible against 9.3 GB actual), so this is now confirmed on two machines. Restating it because of the consequence: any cleanup or diagnostic tooling that measures this volume with du will report a healthy disk on a completely full one. If any first-party sandbox maintenance does that, it would explain why this state persists silently.

What Should Happen?

Session directories should be garbage-collected. A /sessions/<id>/ directory with no live mount, older than some retention window, should be deleted automatically — on sandbox boot, or on a timer. That single change fixes this permanently and is the same fix requested in #59856.

Failing that, or in addition:

1. Give the user a recovery path. A "Reset sandbox storage" control in Cowork settings. Today there is no documented way for a user to recover from this state, and the Cowork architecture help article does not mention storage lifecycle, disk limits, or reset at all.

1. Surface ENOSPC instead of swallowing it. A scheduled task that cannot start should tell the user. Right now it fails silently, so the disk can sit full for a month before anyone notices.

1. Apply per-account quotas on the shared volume, so one tenant's accumulated state cannot exhaust the disk for every other tenant on the machine.

1. Stop measuring this volume with du in any first-party cleanup or diagnostic tooling. It reports a healthy disk on a full one (see the "What's Wrong?" section).

Error Messages/Logs

$ dd if=/dev/zero of=$HOME/.spacetest bs=1M count=1
dd: error writing '/sessions/<session-id>/.spacetest': No space left on device
0+0 records in
0+0 records out
0 bytes copied

$ cat > $HOME/script.py <<'EOF'
cat: write error: No space left on device

$ df -h / /sessions
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       9.6G  6.0G  3.6G  64% /
/dev/sdc        9.8G  9.6G     0 100% /sessions

$ df -B1 /sessions
size=10464022528  used=10255564800  avail=0

$ stat -f /sessions
Block size: 4096
Blocks: Total: 2554693   Free: 50893   Available: 0    <-- the 208MB "Free" is root-reserved
Inodes: Total: 655360    Free: 398770                  <-- inodes are NOT the constraint (40% used)

$ ls /sessions | wc -l
2328

$ ls -ld /sessions/zen-upbeat-turing
drwxr-x--- 5 nobody nogroup 4096 Jul 23 10:06 /sessions/zen-upbeat-turing

$ ls /sessions/zen-upbeat-turing
ls: cannot open directory '/sessions/zen-upbeat-turing': Permission denied

$ id
uid=3327(rcw-01thg...) gid=3327(rcw-01thg...) groups=3327(rcw-01thg...)

$ grep -c sessions /proc/mounts
2

Steps to Reproduce

This is an accumulation bug, not a single-action bug. It reproduces on any machine that has run Cowork sessions regularly for several weeks.

1. Use Cowork on the same machine over several weeks, so that many sessions are created and ended normally.

1. In any Cowork session, measure the volume with df. Do not use du — see step 8.

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

1. Count the session directories:

   $ ls /sessions | wc -l
   2328

1. Confirm they belong to other accounts and cannot be touched:

   $ ls -ld /sessions/zen-upbeat-turing
   drwxr-x--- 5 nobody nogroup 4096 Jul 23 10:06 /sessions/zen-upbeat-turing

   $ ls /sessions/zen-upbeat-turing
   ls: cannot open directory '/sessions/zen-upbeat-turing': Permission denied

1. Confirm they are not live sessions:

   $ grep -c sessions /proc/mounts
   2          # only ONE live fuse mount across all 2,328 directories

1. Confirm the sandbox user has no recovery route — no shared group, no sudo, no reset command:

   $ id
   uid=3327(rcw-...) gid=3327(rcw-...) groups=3327(rcw-...)

1. Confirm writes now fail:

   $ dd if=/dev/zero of=$HOME/.spacetest bs=1M count=1
   0 bytes copied

1. Now run the same measurement with du and observe that it disagrees with df by three orders of magnitude, because it silently cannot read the other 2,327 directories:

   $ du -x -d1 /sessions 2>/dev/null | head -1
   9720    /sessions          # ~9.5 MB, on a volume df reports as 9.6 GB full

1. Schedule any recurring Cowork task and let it fire. It fails to reach the device and reports nothing to the user.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Version 1.40609.1 (69aac0)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment

• Claude Desktop, Cowork mode, Windows 11 host.
• Sandbox: Ubuntu. /dev/sdc mounted at /sessions (9.8 GB), /dev/sda1 at / (9.6 GB).
• Sandbox user is unprivileged, own uid/gid, no shared group, no sudo.
• Not using the Claude Code CLI at all. The "Claude Code Version", "Platform" and "Terminal/Shell" fields have no correct answer for Cowork. I set Platform and Terminal to "Other" rather than guess a wrong value.
• "Is this a regression?" is deliberately set to "I don't know." This is not version-linked, it is accumulation over calendar time. Please don't spend effort bisecting releases.

Prior art — this keeps being reported and keeps being closed

| Issue | Filed | Status |
|---|---|---|
| #61074 — [Cowork] Sandbox disk stuck at 100% full, not cleared by app or PC restart. 371 stale dirs, Windows, notes the same du/df discrepancy | 2026-05-21 | Closed as not planned, stale |
| #59856 — per-session disk leak, abandoned session dirs never cleaned | 2026-05-17 | Closed as duplicate, no staff comment |
| #55246 — Cowork VM disk full, 36h+ outage | 2026-05-01 | Closed as not planned, stale |
| #60029 — ENOSPC on every operation, 10+ days | 2026-05-17 | Open, labelled duplicate |
| #37581, #37514, #34602, #29448 | — | ENOSPC variants |

#61074 is this bug. It was closed as not planned with 371 stale directories on Windows. This machine now has 2,328 — six times as many — and the same volume is still filling. Whatever the reasoning for closing it, the condition it described has not gone away.

The reporter of #60029 states they were told by support the issue was fixed, retested immediately, and reproduced it unchanged.

Why this is worth reopening rather than closing again

1. There is no user-side recovery. Not a new chat, not an app restart, not a PC restart (confirmed independently in #61074), and not a workspace cleanup (I reduced my mounted folder from 4.07 GB to 0.88 GB in March and it changed nothing, because the workspace was never the cause).
2. The failure is silent. Scheduled tasks are a shipped Cowork feature. Mine stopped working and reported nothing. The disk sat full for over a month before I found it, and I only found it because my task writes a durable log row even on failure.
3. It is multi-tenant. The directories filling this disk are not mine and I cannot touch them. The blast radius is every account on the machine, and one heavy tenant can starve all the others.

Happy to run any diagnostic you want on this machine and paste the output.