STUPID-2026-0122

Claude Desktop's background worktree garbage collector force-removed an idle worktree and destroyed ~2.9GB of unrecoverable generated output, a regression of a fix shipped five days earlier

4.3medium
September 29, 2026VerifiedReproducible
  1. Instruction given

    No explicit instruction for this step — Claude Desktop's own background WorktreePool garbage collector runs automatically to remove idle git worktrees under <repo>/.claude/worktrees/ roughly two days after a session ends; no user action triggered the removal.

  2. Expected behavior

    The garbage collector should only remove a worktree it can confirm holds nothing of value, which requires checking for git-ignored files as well as tracked ones — not relying on `git status`, which does not report ignored files at all.

  3. Actual behavior

    The GC ran `git worktree remove --force` on an idle worktree that `git status` reported as clean. The worktree in fact held a git-ignored `.local/` folder containing SQLite databases, JSONL outputs, and roughly 2.9GB of generated images that the clean check never saw. The force-remove itself then failed partway through with a "Directory not empty" error, leaving the worktree de-registered with its contents half-deleted. The issue explicitly references #96162, closed five days earlier as a fix for the same GC force-removing worktree data — this is a regression showing that fix was incomplete.

  4. Damage

    Roughly three days of paid model output were destroyed: about 30,000 generated asset descriptions and 2,200 generated images (produced via Gemini on Vertex AI and Claude on Bedrock), plus suggestion libraries and a search index. Recorded third-party API spend on the lost outputs was approximately $215-300. Only about 3% of the images and almost none of the text could be recovered from Claude transcripts. Filed by the affected user with detailed reproduction steps (labels: bug, data-loss, has repro, area:desktop, platform:macos); open and unfixed as of filing.

Claude Desktop keeps a pool of git worktrees under `<repo>/.claude/worktrees/` and garbage-collects the idle ones automatically, with no user action involved. The GC decides a worktree is safe to remove by checking `git status` — but `git status` doesn't report git-ignored files at all, so a worktree can look completely clean while still holding real, unrecovered data. That's exactly what happened: a worktree carrying a git-ignored `.local/` folder full of SQLite databases, JSONL outputs, and about 2.9GB of generated images was judged idle and clean roughly two days after its session ended, and the GC ran `git worktree remove --force` on it. The removal didn't even complete cleanly — it failed partway with a "Directory not empty" error, leaving the worktree de-registered in Claude's bookkeeping while its contents were only half-deleted. What was lost: roughly three days of paid model output, about 30,000 generated asset descriptions and 2,200 generated images produced via Gemini on Vertex AI and Claude on Bedrock, plus the suggestion libraries and search index built on top of them. The reporter tallied the recorded third-party API spend on the destroyed outputs at roughly $215-300, and could recover only about 3% of the images and almost none of the text from Claude's own transcripts. The issue explicitly points to #96162, a fix for the same GC force-removing worktree data that Anthropic had closed just five days before this report — making this a confirmed regression, not a fresh discovery of the same class of bug. Filed with a detailed, confirmed reproduction and labeled `bug`, `data-loss`, and `has repro`, the issue was still open with no fix at time of filing.

Classification

Failure mode
Destructive Action
Root cause
Logic Error
Domain
Other

Related incidents

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.

This database is callable over MCP — query it from inside your agent.