Windows: orphaned worktree agent processes hold directory lock after session ends, blocking folder deletion

Status Fixed / completed

Maintainer reply None cached

Activity 3 comments · opened Jun 16, 2026 · closed Jun 16, 2026

Summary

When a workflow runs agents with isolation: \"worktree\" on Windows, the child claude.exe processes can survive after the parent session ends. These orphaned processes hold an open handle to the worktree directory, making it impossible to delete the folder through normal means (Explorer, Remove-Item, rd /s /q, robocopy purge all fail with \"file in use\").

Steps to reproduce

Run a Claude Code workflow that uses isolation: \"worktree\" agents on Windows
Close or crash the parent session before the workflow fully completes cleanup
Try to delete the leftover folder under .claude/worktrees/<name>
Deletion fails with \"the file is being used by another process\"

Environment

OS: Windows 11 Pro 10.0.26200
Worktree path was inside OneDrive (may be a contributing factor to cleanup failure)
Platform: win32

What was observed

Three claude.exe processes (PIDs 37684, 38628, 37420) started at ~02:23 and were still running at ~12:20 — nearly 10 hours after the session that spawned them
Combined CPU time: ~1097 seconds — they were actively doing work when abandoned, not just idle
/agents showed nothing — orphaned processes are invisible to Claude Code's own session-scoped tooling
The only way to discover them was via Get-Process claude | Sort-Object StartTime in PowerShell
Killing the three processes immediately released the lock and allowed normal deletion

Expected behavior

Worktree agent processes should terminate and release all handles when the parent session ends or the workflow completes
If cleanup fails, the folder should be removed automatically (or re-attempted on next startup)
/agents (or a new command) should surface orphaned claude processes from all sessions, not just the current one

Workaround

# Find orphaned processes (old StartTime compared to current session)
Get-Process claude | Select-Object Id, Name, StartTime, CPU | Sort-Object StartTime

# Kill the old ones, then delete the folder
Stop-Process -Id <orphaned_pids> -Force
Remove-Item -Recurse -Force ".claude\worktrees\<name>"

# Clean up stale git worktree refs
git worktree prune

View original on GitHub ↗

3 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

yurukusa · 4 months ago

On the OneDrive factor you flagged as "may be contributing" — it almost certainly is, and it's worth separating from the orphaned-process bug because it compounds it:
Why OneDrive makes the lock worse. OneDrive's sync engine (and the Windows Search indexer) both hold open handles on files inside a synced folder. So even after you kill the orphaned claude.exe, the directory can stay "in use" for a moment while OneDrive finishes touching it, and during a session OneDrive is racing the worktree writes for the same handles. Putting a fast-churning, many-small-files workspace like .claude/worktrees/ inside a synced OneDrive path is the worst case for this.
Fix that sidesteps it entirely: point the worktree base outside any OneDrive/Dropbox-synced directory — e.g. C:\cc-worktrees or under %LOCALAPPDATA%. Worktrees are disposable scratch space; they don't benefit from being synced, and keeping them off the sync root removes both the extra handle contention and the post-kill cleanup failures. (If you must keep them synced, "Always keep on this device" behaves better than on-demand for this, but moving them out is cleaner.)
On detection — your Get-Process claude | Sort-Object StartTime is the right call, and it lines up with what others have seen: worktree-isolation workflow agents don't register with the session-scoped /agents view, so cross-session orphans are invisible there by design right now. A pre-session cleanup step that kills claude.exe whose StartTime predates the current session (your exact query, scripted) is a reasonable stopgap until the parent properly reaps its children on exit/crash.
Two genuinely distinct asks in here, fwiw: (1) the parent not reaping worktree children on crash, and (2) orphans being invisible to first-party tooling — they'll likely need separate fixes.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.