Desktop app worktree mechanism wiped gitignored directories from MAIN working tree (data loss; only .gitignore literal-path entries deleted)

Summary

On 2026-07-07 (18:19–18:30 local, GMT+8), the Claude Code desktop app's worktree mechanism appears to have deleted three gitignored directories from the main working tree of my repository — two Python venvs and a cloned third-party repo with local patches and model weights (several GB total). This is a data-destruction-level bug: the directories were not recoverable from git (they were gitignored precisely because they are environment/artifacts), and the first symptom was my production pipeline silently degrading (its route check saw a venv missing and fell back to a legacy path).

Environment

• Claude Code 2.1.201, desktop app (Windows)
• Windows 11 Pro 10.0.26200
• Repo on drive D:, main working tree; desktop-app sessions using isolated worktrees (.claude/worktrees) were in use around that time

Timeline (forensics)

• 18:19:02 — git reflog --date=iso shows the main repo HEAD was checked out to a detached HEAD (checkout: moving from main to <hash>). I did not run this; no interactive session of mine was doing git operations at that time.
• 18:25–18:29 — three directories were emptied/deleted:
• 05_AI_Automation/Auto_Translate/.venv_ocr/
• 05_AI_Automation/Auto_Translate/.venv_inpaint/
• 05_AI_Automation/Auto_Translate/comic-text-detector/
• 18:29:56 — .claude/worktrees directory mtime updated.

The fingerprint: only .gitignore literal-path entries were wiped

This is the detail that points at tooling rather than antivirus/user error. My .gitignore contains both wildcard and literal entries:

.venv_*                                              # (line 26, basename wildcard)
05_AI_Automation/Auto_Translate/.venv_ocr/           # (line 124, literal path)  <- WIPED
05_AI_Automation/Auto_Translate/.venv_inpaint/       # (line 125, literal path)  <- WIPED
05_AI_Automation/Auto_Translate/comic-text-detector/ # (line 131, literal path)  <- WIPED

Sibling venvs in the same directory (.venv_qe, .venv_yolo, .venv_manga_inpaint) that are covered only by the .venv_* wildcard survived untouched. Exactly the three directories listed as literal paths in .gitignore were destroyed. That selectivity is hard to explain by anything except a tool that parses .gitignore and treats literal-path entries differently (e.g., a clean/exclude/copy step in worktree setup or teardown).

Ruled out

• Antivirus: quarantine empty, no detection events in that window (Trend Micro).
• User action: no shell history, no manual deletes; I was not performing git operations.
• Scheduled tasks / other agents: audited; nothing targeting those paths.
• The detached-HEAD checkout of the main tree at 18:19:02 plus the .claude/worktrees mtime at 18:29:56 bracket the deletion window with worktree-mechanism activity on both sides.

Impact

• ~several GB rebuilt from scratch: two venvs (including a GPU torch build that takes significant time to reinstall) and a third-party repo whose local patches existed only in that gitignored directory (my fault for not tracking the patch, but the tool destroyed the only copy).
• Silent production impact: my pipeline's route check requires .venv_inpaint/Scripts/python.exe; when it vanished, jobs silently downgraded to a legacy code path. Data loss with delayed, indirect symptoms is the worst failure mode.

Suggestions (product feedback, from a non-engineer user)

I run a solo translation business and use Claude Code as a non-professional developer. Two suggestions from this incident:

1. Do not enable worktree-based isolation by default for non-engineer users. Worktrees are a great tool for professionals, but for users who don't know git/gitignore semantics, an automatic mechanism that checks out, cleans, or tears down trees can destroy finished work and environment setup they have no idea is at risk — and they have no mental model to even suspect the tool. If worktrees are on by default, the isolation must be provably side-effect-free for the main tree, including gitignored content.
2. Consider a simpler, clearer version-control experience for non-professional users. It can be much less powerful than git, but the interface must make obvious what is protected and what is not. Also please don't architect recovery paths that depend entirely on a GitHub remote — as repos and artifact sizes grow, "it's all on GitHub anyway" is not a safe systemic assumption (gitignored environments/artifacts, like the ones destroyed here, are never on the remote by definition).

I can provide reflog excerpts, directory listings, and .gitignore on request.