[BUG] Measured: `/sessions` refills to 88.6% disk in 16 days after a VM reset, and is never reclaimed — Windows data for #59856

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

**What this report adds, in four lines — the rest is evidence for it:**

1. **A measured refill curve.** A fresh VM reached **88.6% of its disk in 16 days** of ordinary use, then
a second cycle reproduced it. The reset is a workaround against a disk that demonstrably refills.
2. **`never-reaped` on two independent volumes**, 24 samples, the directory count never once falling —
a direct answer to whether anything reclaims these.
3. **This is Windows.** [#59856](https://github.com/anthropics/claude-code/issues/59856) is macOS. Same mechanism, same `useradd` signature, different host OS.
4. **Feedback on the reset button [#59856](https://github.com/anthropics/claude-code/issues/59856) asked for**, which has shipped as two confusable menu items with
the destructive warning on the safer one.

Everything below is the evidence. **This is not a request for help — our machine works.**

#### What we measured

A sampler reads `os.statvfs("/sessions")` plus a `listdir` count on every scheduled run. `/sessions` is
per-machine and a VM rebuild recreates the filesystem, so the series is split by filesystem UUID and never
differenced across a boundary. 24 samples on the affected desktop.

**Cycle 1 — from the 2026-08-21 bundle wipe:**

| | Inodes used | Session dirs | Disk used |
|---|---|---|---|
| 2026-08-21 22:20 (fresh VM) | 2,350 | 3 | 6.8% |
| 2026-09-06 23:01 | 79,439 | 153 | **88.6%** |

16.0 days: +77,089 inodes, +150 session directories, 7.97 GiB of a 9.75 GiB disk.

**Cycle 2 — from a second rebuild on 2026-09-09, still running:**

| | Inodes used | Session dirs | Disk used |
|---|---|---|---|
| 2026-09-09 14:06 (fresh VM) | 77 | 2 | 5.3% |
| 2026-09-13 23:01 | 9,183 | 33 | 37.0% |

4.4 days: +9,106 inodes, +31 session directories, 3.09 GiB.

**1. Session directories are never reclaimed, on two independent volumes.** Across 24 samples the count
has never once fallen. Our verdict function requires a series of *decreases* and gates any negative
finding on elapsed span; it returns **never-reaped** for the desktop volume (17.5 days, 18 samples, net
+154 directories) and independently **never-reaped** for a second machine's volume (22 days, 5 samples,
net +4). Directories created by sessions that *failed to provision* are included — failure does not stop
the accumulation.

**2. The resource that runs out is not the same one each time.** July's failure was **inode** exhaustion
(654,608 of 655,360). Cycle 1 reached **88.6% of disk** with inodes at only 12% of the table. We are not
claiming this distinguishes between candidate fixes — reclaiming the directories would reclaim their bytes
too — but an alarm keyed on inodes alone would not have seen cycle 1 coming.

**3. Consumption is concentrated, so a mean is misleading.** Cycle 1 was strongly non-linear: a single day,
25→26 Aug, accounted for **36,767 inodes — 48% of the entire cycle — for only 8 new session directories**.
Days either side ran in the hundreds. The mean over the first 6 days is roughly double the mean over the
full 16, so we are offering neither a rate nor a predicted refill date. The defensible statement is: **a
fresh VM on this machine reached 88.6% of its disk in sixteen days of ordinary use.**

#### Feedback on the reset button from #59856's suggestion 4

#59856 asked for *"a 'Reset sandbox storage' button in the Claude desktop app's Cowork settings, with a
one-line description of what it does"*. That shipped, as two Troubleshooting menu items that differ by one
word and do very different things:

- **`Delete Cowork VM Bundle and Restart`** recreates the VM — the `/sessions` filesystem UUID changes and
the directory count resets to 2–3.
- **`Delete Cowork VM Sessions and Restart`** clears `/sessions` **in place**. Measured 2026-09-08: inode
use fell 79,439 → 15,430 and disk fell 88.6% → 10.1%, while the **filesystem UUID was unchanged** and the
session-directory count **rose** 153 → 157.

Two consequences. The directories survived a clear-down that emptied their contents — the same
non-reclamation as everywhere else in the series. And the dialogs read the wrong way round: the
**Sessions** dialog carries the "cannot be undone" warning, while **Bundle** re-downloads and is the
recoverable one. The destructive-looking option is the safe one.

#### Background, for completeness

On 2026-07-30 our Cowork sandbox stopped provisioning entirely on one machine, with `/sessions` at
**654,608 of 655,360 inodes used** — the signature in #59856 and #81879. `Delete Cowork VM Bundle and
Restart` fixed it in under five minutes. We then instrumented the volume and sampled it on every scheduled
run for three weeks across two machines, which is where the figures above come from. #59856's diagnosis —
per-session directories never garbage-collected, plus unbounded caches — is the one this corroborates.

### What Should Happen?

1. **Stale `/sessions//` directories should be garbage-collected**, or the caches named in [#59856](https://github.com/anthropics/claude-code/issues/59856)
capped. *We are not re-asking for this — [#59856](https://github.com/anthropics/claude-code/issues/59856) already did. We are supplying the measurement it
lacked:* a reset that refills to 88.6% of disk in sixteen days is a workaround, not a fix.
2. **The condition should be surfaced in-product before it bites.** Today the first symptom is that
scheduled work silently does not run. The sandbox cannot self-diagnose — `df -i /sessions` is
unavailable once the shell will not start — so the user learns by noticing an absence. A warning before
the disk fills, or an error naming the cause and the reset path, would remove most of the cost.
3. **The two Delete-Cowork menu items should be distinguishable**, and the destructive warning should sit
on the destructive one.
4. **[#36465](https://github.com/anthropics/claude-code/issues/36465) / [#43850](https://github.com/anthropics/claude-code/issues/43850) / [#56439](https://github.com/anthropics/claude-code/issues/56439) / [#59856](https://github.com/anthropics/claude-code/issues/59856) should have a stated owner and status.** All four were closed as
stale or duplicate **by a bot rather than by a maintainer confirming a fix shipped**, so their closed
state should not be read as resolution.

### Error Messages/Logs

```shell
RPC error: ensure user: useradd failed: exit status 12:
useradd: cannot create directory /sessions/

# /sessions at the time of failure, 2026-07-30:
# 655,360 inodes total, 654,608 used, 752 free
# A fresh VM on the same machine, 2026-08-21, immediately after the bundle wipe:
# Filesystem Inodes IUsed IFree IUse% Mounted on
# /dev/sdc 655360 73 655287 1% /sessions
```

### Steps to Reproduce

**This is not a single-action bug — it is a slow accumulation.** Organic reproduction:

1. Use Cowork mode in the Claude desktop app with at least one scheduled task running daily.
2. Sample `/sessions` on each run: `os.statvfs("/sessions")` plus `len(os.listdir("/sessions"))`.
3. Observe the session-directory count rise monotonically and never fall. Ours went 3 → 153 in sixteen
days, with disk use going 6.8% → 88.6%.
4. Eventually provisioning fails inside `useradd` and every subsequent session — including scheduled
tasks — fails with no surfaced error.

**Forced reproduction for development:** fill the sandbox's `/sessions` to ~100%, then start a new
session; the `useradd` failure reproduces immediately. #59856 gives the same recipe for macOS.

### Claude Model

None

### Is this a regression?

No, this never worked

### 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. Desktop app version **1.49585.0.0**. Sandbox image is Ubuntu 22.

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

No terminal is involved; the failure is inside the app's own sandbox. The in-sandbox shell is bash
on Ubuntu 22.

No source file or test is identified. Start with the Cowork sandbox provisioning path that invokes useradd for /sessions, reproduce the forced full-volume failure, and trace the two Troubleshooting reset actions. Done requires an agreed scope covering reclamation or cache bounds, a surfaced failure or warning, and clearly differentiated reset dialogs with the destructive warning on the destructive action.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.