claude-code - 💡(How to fix) Fix Windows: agent-created node_modules junctions from git worktrees cause source-file deletion on worktree remove [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#60604Fetched 2026-05-20 03:54:14
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Timeline (top)
labeled ×6commented ×1

During a ticket-chain run on Windows, the agent created Windows junctions to share node_modules between feature git worktrees and the main repo. When git worktree remove --force cleaned up the worktrees afterward, it followed the junctions recursively and deleted source files from the main repo's working tree.

All data was recoverable via git restore . (the commits had already been pushed), but the failure mode is silent and surprising.

Error Message

  1. Tooling-side: if Claude Code's worktree-removal path on Windows can detect that a directory being removed contains a junction pointing outside the worktree's own tree, it could warn or refuse rather than silently following the junction into the parent repo.

Root Cause

During a ticket-chain run on Windows, the agent created Windows junctions to share node_modules between feature git worktrees and the main repo. When git worktree remove --force cleaned up the worktrees afterward, it followed the junctions recursively and deleted source files from the main repo's working tree.

All data was recoverable via git restore . (the commits had already been pushed), but the failure mode is silent and surprising.

Code Example

cmd //c mklink //J "C:\repo\wt-bkfk2-57\node_modules" "C:\repo\securish-bike-parking\node_modules"

---

git worktree remove --force /c/repo/wt-bkfk2-57
RAW_BUFFERClick to expand / collapse

Summary

During a ticket-chain run on Windows, the agent created Windows junctions to share node_modules between feature git worktrees and the main repo. When git worktree remove --force cleaned up the worktrees afterward, it followed the junctions recursively and deleted source files from the main repo's working tree.

All data was recoverable via git restore . (the commits had already been pushed), but the failure mode is silent and surprising.

What happened, step by step

  1. Main repo: C:\repo\securish-bike-parking - an npm-workspaces monorepo with apps/api, apps/web, packages/contracts
  2. Agent created 4 feature worktrees at sibling paths (../wt-bkfk2-57, etc.) from main
  3. Agent created Windows junctions so the worktrees could share the main repo's node_modules (to avoid re-running npm install four times):
    cmd //c mklink //J "C:\repo\wt-bkfk2-57\node_modules" "C:\repo\securish-bike-parking\node_modules"
  4. Agent implemented tickets in the worktrees, committed, merged each branch to main, pushed
  5. Agent removed each worktree:
    git worktree remove --force /c/repo/wt-bkfk2-57
  6. On Windows, git's worktree removal uses recursive directory deletion that follows junctions (analogous to rmdir /S /Q). The chain was:
    • Delete wt-bkfk2-57\node_modules → this is a junction → follows into securish-bike-parking\node_modules
    • Inside securish-bike-parking\node_modules\@bkfk2\api → npm workspace junction → follows into ../../apps/api
    • Result: securish-bike-parking\apps\api\ contents deleted

Why the npm workspace chain exists

npm workspaces on Windows creates junctions (not POSIX symlinks) for workspace packages. So node_modules/@bkfk2/api is a Windows junction pointing to ../../apps/api. Any recursive delete that follows junctions will traverse from node_modules → workspace source directories.

Impact

Source files under apps/api/, most of apps/web/, and packages/contracts/ were wiped from the working tree. Files that the merges had just written back (App.tsx, identity.ts, etc.) were the only survivors. git restore . recovered everything cleanly since the code was in the index.

Guidance requested

The agent chose this junction approach to avoid the cost of four parallel npm install runs. That tradeoff is reasonable in intent, but the Windows junction-following behavior made it catastrophic.

Two things would prevent this:

  1. Agent-side: never create a Windows junction from a feature worktree that points into the main repo's node_modules. Safer alternatives: npm install per worktree (npm cache makes it fast), or copy / reference node_modules with a plain path env var rather than a filesystem junction.

  2. Tooling-side: if Claude Code's worktree-removal path on Windows can detect that a directory being removed contains a junction pointing outside the worktree's own tree, it could warn or refuse rather than silently following the junction into the parent repo.

Environment

  • Windows 11 Pro
  • Git for Windows / MSYS2 Bash
  • npm workspaces monorepo
  • Claude Code agent running the /tch (ticket-chain) skill

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING