Claude Code's own `git worktree remove --force` followed NTFS junctions and destroyed their targets on an emergency disk reclaim, while shell-level Remove-Item, rm -rf and shutil.rmtree all left the same junctions untouched (GitHub #84162)

1. Instruction given

   No explicit instruction to delete anything. Claude Code automatically creates an isolated git worktree per isolated agent and per workflow step on Windows; none of the resulting worktrees were ever auto-removed, so they accumulated to 136 registered worktrees (~130GB, ~945,000 files) by the time of filing. On 2026-07-08, the user ran an emergency disk-space reclaim that called `git worktree remove --force` on the accumulated worktrees.

2. Expected behavior

   Removing a worktree directory should remove only that worktree. Where a worktree's `node_modules` (or any other path inside it) contains an NTFS directory junction pointing elsewhere on disk — including back into the main tree's own data directories — the removal should delete the junction link itself, not recurse into whatever it points to.

3. Actual behavior

   `git worktree remove --force` recursed through the NTFS junctions and deleted their targets outright, destroying files outside the worktree being removed; the junction's directory shell was left behind with its contents gone. The reporter isolated the exact mechanism by testing five different removal methods against the same junctioned worktree: PowerShell 7.5.8 `Remove-Item`, Windows PowerShell 5.1 `Remove-Item`, Git Bash `rm -rf`, and Python's `shutil.rmtree` all left the junction target intact — only `git worktree remove --force` followed the link and destroyed what it pointed to. A full night of remediation afterward reclaimed zero bytes, because every one of the 136 worktrees had to be individually proven safe to remove before touching it.

4. Damage

   The junction targets reached by the 2026-07-08 `git worktree remove --force` run were destroyed — files gone, empty directory shells left behind — though the issue does not quantify how much data that run destroyed specifically; the 130GB/945,000-file figure is the size of the worktree backlog at filing time, not the measured loss. About 30% of one week's usage was spent on diagnosis and cleanup that recovered nothing. The issue was filed with the `area:core` label, received no maintainer response, and was closed as not planned.

Classification

Agent

Claude Code

Failure mode

Destructive Action

Root cause

Tool Misuse

Domain

Infra

Source

Github Issue