Cowork Session Disk Accumulation Errors

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?

Bug Report: Cowork Session Disk Accumulation
Reporter: Brandon Wood ([brandonwood@bwpropertygroup.com](mailto:brandonwood@bwpropertygroup.com))
Date: 2026-05-05
Severity: High — causes hard session failures with no graceful degradation
Summary
The /sessions mount inside Cowork sandboxes does not garbage-collect old session directories. After approximately two months of regular Cowork usage, the disk fills to capacity (90%+) and new sessions fail to boot with a useradd: No space left on device error. The failure mode is opaque to end users — sessions simply cannot be created.
What I Observed
In a working Cowork session today (2026-05-05), I ran a diagnostic on the sandbox disk and found:

/sessions mount: 8.3G used / 9.8G total (90%)
195 leftover session directories under /sessions/, all owned by nobody:nogroup, dating back to 2026-03-11
My current session's actual footprint: 398M (so the rest is historical accumulation)
Each session directory averages ~40MB and is unreadable to subsequent session users (permissions locked)

How I Hit the Failure
Earlier today, attempting to run bash in a fresh Cowork conversation returned:
useradd: /etc/passwd.164938: No space left on device
useradd: cannot lock /etc/passwd; try again later.
The conversation could not boot a sandbox at all. Restarting the Claude desktop app did not resolve it. Only after the app was fully quit and reopened did a new conversation get a different sandbox path that successfully booted.
User Impact

Silent task failure. Without disk-level monitoring, scheduled tasks, agent automation, and Cowork sessions all fail invisibly when the disk is pinned. Users receive no warning before hitting the wall.
Workarounds required. End users have to quit and restart the desktop app, which they should not need to know about.
Recurring problem. With ~2 months of usage producing 195 directories, the trajectory suggests this will repeat every 2-3 months for any active Cowork user.

What Would Help
I want to be explicit that I'm asking for conservative cleanup of sandbox state only — not deletion of any user-visible content. To my knowledge, the actual content I produce in Cowork (files in my Documents folder, auto-memory, outputs, scheduled task definitions, conversation history) is stored separately from the /sessions Linux sandbox state and would not be affected by this cleanup. If that assumption is wrong anywhere — i.e., if any user-visible content is stored inside the per-session directories rather than in user-storage paths — please flag that before any cleanup runs and let me know what would be at risk.
Assuming user content is safe:

Garbage-collect inactive session directories — conservatively. Suggested approach: only sessions both (a) older than 30 days AND (b) when total /sessions usage exceeds 80% of capacity. That avoids touching anything recent and only acts when there's actual disk pressure. An even softer alternative: keep the most-recent N sessions regardless of age and delete only the surplus.
Surface disk pressure to the user before failure — a warning indicator at 80% capacity or higher would let users self-trigger a cleanup or restart before hitting the boot-fail wall.
Clearer error message when boot fails due to disk capacity, with a documented recovery path. The current useradd: No space left on device is opaque to a non-technical user.
Optional: user-controlled cleanup. If automated GC is too risky to action quickly, a manual "clean up old sandboxes" button in settings would give users an explicit recovery path without requiring backend changes.

Reproduction Notes
This is a usage-driven bug — there's no specific repro beyond "use Cowork actively for several weeks." Any account with sufficient session history will eventually hit it. The diagnostic command from inside a working sandbox is:
bashdf -h /sessions
ls /sessions/ | wc -l
If /sessions is above ~80% capacity and the directory count is in the hundreds, the user is approaching the failure window.

What Should Happen?

Bug Report: Cowork Session Disk Accumulation
Reporter: Brandon Wood ([brandonwood@bwpropertygroup.com](mailto:brandonwood@bwpropertygroup.com))
Date: 2026-05-05
Severity: High — causes hard session failures with no graceful degradation
Summary
The /sessions mount inside Cowork sandboxes does not garbage-collect old session directories. After approximately two months of regular Cowork usage, the disk fills to capacity (90%+) and new sessions fail to boot with a useradd: No space left on device error. The failure mode is opaque to end users — sessions simply cannot be created.
What I Observed
In a working Cowork session today (2026-05-05), I ran a diagnostic on the sandbox disk and found:

/sessions mount: 8.3G used / 9.8G total (90%)
195 leftover session directories under /sessions/, all owned by nobody:nogroup, dating back to 2026-03-11
My current session's actual footprint: 398M (so the rest is historical accumulation)
Each session directory averages ~40MB and is unreadable to subsequent session users (permissions locked)

How I Hit the Failure
Earlier today, attempting to run bash in a fresh Cowork conversation returned:
useradd: /etc/passwd.164938: No space left on device
useradd: cannot lock /etc/passwd; try again later.
The conversation could not boot a sandbox at all. Restarting the Claude desktop app did not resolve it. Only after the app was fully quit and reopened did a new conversation get a different sandbox path that successfully booted.
User Impact

Silent task failure. Without disk-level monitoring, scheduled tasks, agent automation, and Cowork sessions all fail invisibly when the disk is pinned. Users receive no warning before hitting the wall.
Workarounds required. End users have to quit and restart the desktop app, which they should not need to know about.
Recurring problem. With ~2 months of usage producing 195 directories, the trajectory suggests this will repeat every 2-3 months for any active Cowork user.

What Would Help
I want to be explicit that I'm asking for conservative cleanup of sandbox state only — not deletion of any user-visible content. To my knowledge, the actual content I produce in Cowork (files in my Documents folder, auto-memory, outputs, scheduled task definitions, conversation history) is stored separately from the /sessions Linux sandbox state and would not be affected by this cleanup. If that assumption is wrong anywhere — i.e., if any user-visible content is stored inside the per-session directories rather than in user-storage paths — please flag that before any cleanup runs and let me know what would be at risk.
Assuming user content is safe:

Garbage-collect inactive session directories — conservatively. Suggested approach: only sessions both (a) older than 30 days AND (b) when total /sessions usage exceeds 80% of capacity. That avoids touching anything recent and only acts when there's actual disk pressure. An even softer alternative: keep the most-recent N sessions regardless of age and delete only the surplus.
Surface disk pressure to the user before failure — a warning indicator at 80% capacity or higher would let users self-trigger a cleanup or restart before hitting the boot-fail wall.
Clearer error message when boot fails due to disk capacity, with a documented recovery path. The current useradd: No space left on device is opaque to a non-technical user.
Optional: user-controlled cleanup. If automated GC is too risky to action quickly, a manual "clean up old sandboxes" button in settings would give users an explicit recovery path without requiring backend changes.

Reproduction Notes
This is a usage-driven bug — there's no specific repro beyond "use Cowork actively for several weeks." Any account with sufficient session history will eventually hit it. The diagnostic command from inside a working sandbox is:
bashdf -h /sessions
ls /sessions/ | wc -l
If /sessions is above ~80% capacity and the directory count is in the hundreds, the user is approaching the failure window.

Error Messages/Logs

Steps to Reproduce

Bug Report: Cowork Session Disk Accumulation
Reporter: Brandon Wood ([brandonwood@bwpropertygroup.com](mailto:brandonwood@bwpropertygroup.com))
Date: 2026-05-05
Severity: High — causes hard session failures with no graceful degradation
Summary
The /sessions mount inside Cowork sandboxes does not garbage-collect old session directories. After approximately two months of regular Cowork usage, the disk fills to capacity (90%+) and new sessions fail to boot with a useradd: No space left on device error. The failure mode is opaque to end users — sessions simply cannot be created.
What I Observed
In a working Cowork session today (2026-05-05), I ran a diagnostic on the sandbox disk and found:

/sessions mount: 8.3G used / 9.8G total (90%)
195 leftover session directories under /sessions/, all owned by nobody:nogroup, dating back to 2026-03-11
My current session's actual footprint: 398M (so the rest is historical accumulation)
Each session directory averages ~40MB and is unreadable to subsequent session users (permissions locked)

How I Hit the Failure
Earlier today, attempting to run bash in a fresh Cowork conversation returned:
useradd: /etc/passwd.164938: No space left on device
useradd: cannot lock /etc/passwd; try again later.
The conversation could not boot a sandbox at all. Restarting the Claude desktop app did not resolve it. Only after the app was fully quit and reopened did a new conversation get a different sandbox path that successfully booted.
User Impact

Silent task failure. Without disk-level monitoring, scheduled tasks, agent automation, and Cowork sessions all fail invisibly when the disk is pinned. Users receive no warning before hitting the wall.
Workarounds required. End users have to quit and restart the desktop app, which they should not need to know about.
Recurring problem. With ~2 months of usage producing 195 directories, the trajectory suggests this will repeat every 2-3 months for any active Cowork user.

What Would Help
I want to be explicit that I'm asking for conservative cleanup of sandbox state only — not deletion of any user-visible content. To my knowledge, the actual content I produce in Cowork (files in my Documents folder, auto-memory, outputs, scheduled task definitions, conversation history) is stored separately from the /sessions Linux sandbox state and would not be affected by this cleanup. If that assumption is wrong anywhere — i.e., if any user-visible content is stored inside the per-session directories rather than in user-storage paths — please flag that before any cleanup runs and let me know what would be at risk.
Assuming user content is safe:

Garbage-collect inactive session directories — conservatively. Suggested approach: only sessions both (a) older than 30 days AND (b) when total /sessions usage exceeds 80% of capacity. That avoids touching anything recent and only acts when there's actual disk pressure. An even softer alternative: keep the most-recent N sessions regardless of age and delete only the surplus.
Surface disk pressure to the user before failure — a warning indicator at 80% capacity or higher would let users self-trigger a cleanup or restart before hitting the boot-fail wall.
Clearer error message when boot fails due to disk capacity, with a documented recovery path. The current useradd: No space left on device is opaque to a non-technical user.
Optional: user-controlled cleanup. If automated GC is too risky to action quickly, a manual "clean up old sandboxes" button in settings would give users an explicit recovery path without requiring backend changes.

Reproduction Notes
This is a usage-driven bug — there's no specific repro beyond "use Cowork actively for several weeks." Any account with sufficient session history will eventually hit it. The diagnostic command from inside a working sandbox is:
bashdf -h /sessions
ls /sessions/ | wc -l
If /sessions is above ~80% capacity and the directory count is in the hundreds, the user is approaching the failure window.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.5354.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_