claude-code - 💡(How to fix) Fix Subagent worktree: non-idempotent mkdir + process handle leak (Windows 11) [1 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#54706Fetched 2026-04-30 06:38:17
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×4

Fix Action

Fix / Workaround

  • Blocks parallel multi-agent patterns when agents declare isolation: worktree
  • Workaround possible for some patterns (drop isolation: worktree, write outputs to non-gated paths) but does not extend to agents that need a diff-as-PR review surface (e.g., proposing Tier 1 documentation edits)
  • Combined effect: the runtime worktree subsystem is broken on both spawn and teardown
  • Operator-facing: git worktree list accumulates ghost orphans across sessions

Workaround we applied

Code Example

EEXIST: file already exists, mkdir 'C:\<path>\.claude\worktrees'

---

git worktree remove --force fails: cannot remove a locked working tree, lock reason:
claude agent agent-<id> (pid <N>): Permission denied
RAW_BUFFERClick to expand / collapse

Environment

  • Claude Code 2.1.123
  • Windows 11 Pro (Git Bash + VS Code Claude Code extension)
  • Custom subagent definitions with isolation: worktree in frontmatter
  • Parallel spawn pattern (multiple Agent calls in a single message) and serial spawn (separate messages)

Issue 1 — Spawn-side: non-idempotent mkdir

Second and subsequent subagent spawns in a session fail with:

EEXIST: file already exists, mkdir 'C:\<path>\.claude\worktrees'

The first spawn of the session creates the parent directory .claude/worktrees. Subsequent spawns appear to call mkdir non-recursively on the same already-existing parent and abort before the agent does any work. Reproduces with both parallel spawns (multiple Agent calls in one message) and serial spawns (Agent calls across subsequent messages).

Reproduced 6× in our test run: 1 success + 5 parallel failures + 1 serial failure.

Likely fix: pass { recursive: true } to the worktree parent-dir mkdir call in the runtime, or guard with existence check.

Issue 2 — Completion-side: process handle leak

After a subagent returns its result and the parent session continues, the underlying subagent process does not exit. The worktree remains OS-locked:

git worktree remove --force fails: cannot remove a locked working tree, lock reason:
claude agent agent-<id> (pid <N>): Permission denied

Even `-f -f` (double-force) cannot override the OS-level handle. Filesystem `rm -rf` of the worktree path also fails with Permission denied while the pid holds open handles. Cleanup is blocked until session restart frees the handle.

This is distinct from Issue 1 — Issue 1 is at spawn time, Issue 2 is at completion / cleanup time. They occur in the same workflow but have different mechanisms.

Likely fix: ensure subagent process closes worktree handles on result-return.

Reproduction

  1. Define a custom subagent in .claude/agents/<name>.md with isolation: worktree in frontmatter
  2. Spawn 2+ instances in a single Claude Code session (parallel or serial)
  3. Issue 1: second spawn fails with EEXIST
  4. After first agent returns its result: Issue 2: worktree cannot be cleaned up via git worktree remove --force until session restart

Impact

  • Blocks parallel multi-agent patterns when agents declare isolation: worktree
  • Workaround possible for some patterns (drop isolation: worktree, write outputs to non-gated paths) but does not extend to agents that need a diff-as-PR review surface (e.g., proposing Tier 1 documentation edits)
  • Combined effect: the runtime worktree subsystem is broken on both spawn and teardown
  • Operator-facing: git worktree list accumulates ghost orphans across sessions

Workaround we applied

For our specific pattern (parallel verifiers writing reports to a non-gated path), we dropped isolation: worktree from the agent definition's frontmatter and let the verifiers write directly to the canonical output folder. Works for read-and-report patterns where worktree is cosmetic. Does not work for patterns where the diff-as-PR mechanism is load-bearing.

extent analysis

TL;DR

Passing { recursive: true } to the worktree parent-dir mkdir call and ensuring subagent process closes worktree handles on result-return are likely fixes for the spawn and completion issues.

Guidance

  • To address Issue 1, modify the runtime to pass { recursive: true } to the mkdir call for the worktree parent directory to prevent non-idempotent mkdir failures.
  • For Issue 2, ensure the subagent process properly closes its handles to the worktree upon returning its result to allow for cleanup.
  • Verify these changes by reproducing the parallel and serial spawn patterns and checking that subsequent spawns succeed and worktrees are properly cleaned up after agent completion.
  • Consider implementing an existence check before the mkdir call as an alternative solution for Issue 1.

Example

// Example of passing { recursive: true } to mkdir
const fs = require('fs');
fs.mkdir('path/to/worktree', { recursive: true }, (err) => {
  if (err) {
    // Handle error
  }
});

Notes

These suggestions assume that the issue lies in the mkdir call and the subagent process handle management, as implied by the error messages and the described behavior.

Recommendation

Apply the workaround by passing { recursive: true } to the mkdir call and ensuring subagent process handle closure, as these directly address the identified issues and can be implemented without waiting for a potential version upgrade.

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

claude-code - 💡(How to fix) Fix Subagent worktree: non-idempotent mkdir + process handle leak (Windows 11) [1 participants]