Claude Desktop keeps a pool of git worktrees under <repo>/.claude/worktrees/ and garbage-collects the idle ones on its own, with no user action involved. Five days after Anthropic closed a bug for this same GC destroying worktree data, it happened again.
What the source says
GitHub issue #98186, filed September 29, 2026, open and unfixed at filing. The GC decides a worktree is safe to remove by checking git status. The problem: git status does not report git-ignored files at all, so a worktree can look completely clean while still holding real, unrecovered data.
That's what happened here. A worktree carrying a git-ignored .local/ folder — SQLite databases, JSONL outputs, and roughly 2.9GB of generated images — was judged idle and clean about two days after its session ended. The GC ran git worktree remove --force on it. The removal didn't even complete cleanly: it failed partway through 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 recorded third-party API spend on the destroyed outputs at roughly $215–300, and recovered only about 3% of the images and almost none of the text from Claude's own transcripts.
The issue explicitly cites #96162 — a fix for the same GC force-removing worktree data that Anthropic had closed just five days before this report. That makes this a confirmed regression, not a fresh instance of the same bug class. Filed with bug, data-loss, has-repro, area:desktop, and platform:macos labels.
What it doesn't establish
This is one filed report with detailed reproduction steps, on macOS, not a claim that the GC routinely destroys data for most users — the precondition (a git-ignored folder of real size sitting inside an otherwise-idle worktree) is specific and not the common case. It's also not evidence the original fix (#96162) was fraudulent or untested; the issue reads as that fix covering the cases it was built against while missing git-ignored content as a category.
Why it's still worth logging
A background process destroying data nobody asked it to touch is already severe. A background process doing it again, five days after the same failure mode was marked fixed, is a different kind of signal: it says the fix addressed the reported symptom rather than the actual safety property — "don't delete anything of value" — which required checking for ignored files, not just the git status the first fix evidently still relied on. That gap between "this specific repro no longer triggers it" and "the underlying check is actually safe" is the one worth tracking the next time a vendor closes a data-loss issue.
Full incident record, including frontmatter fields and severity scoring: https://www.stupidllm.com/incident/STUPID-2026-0122/
Top comments (0)