Never touch .claude/worktrees/ in any repo. Never touch git worktrees, submodules, gitlinks, or agent-spawned ephemeral dirs in repos outside your current working scope.
Worktrees belong to the project that owns them. If private-project housekeeping touches file X in repo Y, that does NOT extend to .claude/worktrees/ in repo Y. Worktrees are the private state of whichever agent, session, or human spawned them. They may look orphaned and aren't.
rm -rf .claude/worktrees/ in any repogit rm or git rm --cached worktree entriesgit add -A (this is the subtle one — -A sweeps up changes you didn't intend).claude/worktrees/ pathsagent-<hash> look like ephemeral agent artifacts but may be active sessionsDuring a private-project ecosystem-wide "commit + push all tool repos" pass, git add -A in flarecrawl staged gitlinks to 9 agent worktrees (from background agents running inside flarecrawl). Those gitlinks were committed and pushed as part of "chore: sync tool state". Then a subsequent rm -rf .claude/worktrees/ deleted the filesystem dirs, creating a dirty state. The user correctly pushed back — private-project housekeeping has no business touching another project's agent state.
git add, not -A or ., when the repo contains any .claude/ directorygit status --short before any bulk commit loop; if .claude/worktrees/ appears, STOP and ask.claude/ state looks "dirty" during cross-project work, that's the repo's problem, not yoursAll projects. Never make exceptions "just for this session". If a worktree ever looks like it needs cleanup, ask the user explicitly before touching it.