.claude/worktrees/ directories are silently recreated after deletion, even with Desktop closed and no owning process found
Environment:
- Claude Code CLI: 2.1.220
- macOS: 26.5.2 (BuildVersion 25F84), Darwin 25.5.0, arm64
- Claude Desktop app also installed (confirmed fully quit during testing, see below)
Description:
Two directories under <repo>/.claude/worktrees/ (from past EnterWorktree sessions on now-merged tickets) persisted across repeated rm -rf, being recreated within ~5 seconds every time, even with:
- The Bash tool's sandbox disabled (
dangerouslyDisableSandbox: true) - Claude Desktop fully quit (Cmd+Q, verified via
ps aux— zero related processes) - No tmux, cron, launchd agent, or mount responsible (all checked and ruled out)
These aren't real git worktrees: no .git file/dir inside either directory, neither appears in git worktree list, and git rev-parse --show-toplevel run from inside one just resolves up to the parent repo. The content looks like a partial copy of several tracked top-level directories and files from the repo, refreshed to current HEAD each time (one of the copied files matched a same-day commit exactly) — not a stale snapshot from when the work actually happened.
By elimination, the only remaining candidate is the Claude Code CLI installation itself doing background reconciliation against a worktree registry that outlives the session that created it — consistent with ExitWorktree's own docs, which explicitly refuse to touch "worktrees from a previous session (even if created by EnterWorktree then)," implying such a registry exists. Neither ExitWorktree (scoped to the current session) nor EnterWorktree with path (requires the path to be in git worktree list, which these aren't) can reach it.
Impact: Completed, merged work leaves permanently un-cleanable directory state behind, with no tool or command able to remove it. The recreated content also partially mirrors the private repo's structure, which is unwanted for a leftover that's supposed to be inert.
---
Drafted with Claude Code's help while investigating the issue live.
3 Comments
Update: false alarm on Claude Code — root cause was Docker Desktop's synchronized file share, not the CLI.
Turned out this had nothing to do with Claude Code's worktree registry. The repo's root directory was configured as a Docker Desktop synchronized file share (bidirectional sync between host and container VM, not a plain bind mount), used by a container that bind-mounted the whole repo root.
Docker Desktop's own Settings → Resources → File sharing panel showed live "Problems" entries for the exact leftover path we were chasing:
The container's Rails/Sprockets process had written asset cache files under that path at some point; Docker's sync engine kept mirroring the container-side copy back down to the host every time we deleted it on disk — instantly, regardless of the Bash tool's sandbox setting, and regardless of whether Claude Desktop (a completely different app) was running or not. That's why every filesystem-level test we ran (tmux, cron, launchd, mounts, quitting Claude Desktop) came back clean: the actual daemon responsible was Docker Desktop's, which we hadn't thought to check.
Fix: removed the never-started container that was pinning the share ("Used by"), then deleted the synchronized file share itself via Docker Desktop's UI. The directories have stayed deleted since.
Apologies for the noise — closing this out since Claude Code isn't at fault here. Leaving the writeup in case anyone else hits the same "impossible to delete" symptom and it turns out to be Docker Desktop's file sync rather than Claude Code.
Closing per the finding above — root cause identified as Docker Desktop's synchronized file share, not Claude Code.
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.