[BUG] Parallel subagent worktree cleanup destroys .git directory and entire working tree — catastrophic data loss

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?

Running two rounds of parallel subagents with isolation: worktree resulted in the complete destruction of the .git/ directory and nearly all working tree files. This is not a branch deletion or uncommitted change loss — the entire repository, including git history, was irreversibly destroyed.

After the incident, only a handful of files written by the second round of agents remained on disk. Everything else — source code, documentation, tests, configuration, and the .git/ directory itself — was gone.

What Should Happen?

Expected Behavior

After subagent worktree cleanup, the main working tree and .git/ directory should remain intact. At minimum:

• The .git/ directory must never be deleted
• Files in the main working tree that are not part of a worktree must not be removed
• Committed work should be preserved

Actual Behavior

After the Layer 2 agents completed and their worktrees were cleaned up:

• .git/ directory: completely gone
• All original source code: gone (the entire package that existed before the session)
• All documentation (docs/): gone
• All tests (tests/): gone
• README.md, configuration files: gone
• Layer 1 committed modules (4 commits worth of new code): gone
• Only surviving files: a few files written by Layer 2 agents (install.sh, uninstall.sh, pyproject.toml)

The branch was not pushed to remote, so all git history is permanently lost.

Error Messages/Logs

Steps to Reproduce

1. Open a Claude Code session in a git repository on branch dev/mode-2
2. Launch 4 parallel subagents with isolation: worktree (Layer 1: implementing M06, M02, M01, M04 modules)
3. Wait for all 4 agents to complete (~15 minutes). They produce files in the main working directory.
4. Commit the results (4 separate git commit commands — commits 55a4fe3 through 88b6f9c were created successfully)
5. Launch another round of 4 parallel subagents with isolation: worktree (Layer 2: M07, M03, M05, M01-deploy)
6. Wait for all 4 Layer 2 agents to complete (~8 minutes)
7. Attempt any git operation → fatal: not a git repository (or any of the parent directories): .git

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.109

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

PyCharm terminal

Additional Information

Diagnosis

The worktree cleanup mechanism appears to have operated on the main working tree instead of (or in addition to) the isolated worktree directories. During Layer 2, multiple worktrees were created and cleaned up in parallel. The cleanup process seems to have:

1. Removed the .git/ directory (or corrupted it beyond recovery)
2. Deleted tracked files from the main working tree
3. Left behind only the files that Layer 2 agents had written (possibly because they were written to the main working tree rather than their respective worktrees)

This is a race condition or path confusion in the worktree lifecycle management. The cleanup of one worktree may have targeted the main repository root.

Key Details

• Layer 1 worktrees were created, agents completed, and worktrees were cleaned up successfully (commits landed in main working tree)
• The destruction happened during/after Layer 2 worktree cleanup
• git worktree list after the incident returned "no worktrees" (because .git/ was gone)
• find confirmed no .git directory existed anywhere under the project root
• The .claude/worktrees/ directory was empty

Impact

• Complete, irrecoverable loss of an entire codebase (source, docs, tests, git history)
• All work from the current session (Layer 1 commits) also lost
• No recovery possible because .git/ was destroyed and the branch was never pushed

Related Issues

• #38287 — Worktree cleanup silently deletes branches with unmerged commits (same category, less severe)
• #29110 — Spawned agents: worktree data loss (similar parallel agent scenario)
• #12586 — Worktree created without user consent, potential data loss
• #37331 — Claude deleted all files, .git replaced

This is the most severe variant: not just branch/commit loss, but destruction of the .git/ directory itself, making recovery impossible even with git fsck.

Suggested Fix

1. Never delete or modify the main .git/ directory during worktree cleanup — add an explicit guard
2. Never delete files from the main working tree during worktree cleanup — validate that the cleanup path is under .claude/worktrees/ before removing anything
3. Add a pre-cleanup safety check: verify that the path being cleaned is actually a worktree (e.g., contains a .git file pointing to the main repo, not a .git directory)
4. Consider refusing to clean up worktrees in parallel — serialize the cleanup to avoid race conditions