Worktree Ownership Boundary: Never Remove Worktrees You Didn't Create

Worktree Ownership Boundary

Problem

After completing agent team work, the leader agent cleaned up worktrees by listing git worktree list and removing all entries under .claude/worktrees/. One worktree (audit-items) belonged to the user from a previous session — it contained in-progress work on Linear epic implementations (INK-360, INK-361, INK-363, INK-370). The force removal destroyed the working directory and its uncommitted changes.

Symptoms:

• User’s in-progress work lost (working directory deleted)
• Branch was recoverable via git branch <name> <sha> but uncommitted changes were gone
• User rightfully furious

Root Cause

The agent assumed all worktrees under .claude/worktrees/ were created by the current session’s agents. It ran git worktree remove --force without checking:

1. Whether the worktree was created by this session
2. Whether it contained modified or untracked files (the non---force attempt warned about this!)
3. Whether the user had any active work there

The --force flag was used specifically to bypass the “contains modified or untracked files” safety check — the exact check designed to prevent this scenario.

Solution

Hard Rule: NEVER Remove Worktrees You Didn’t Create

Agent-created worktrees are automatically cleaned up by the Task tool’s worktree isolation. The leader should NEVER manually remove worktrees.

If Manual Cleanup Is Needed

1. Only remove worktrees created by agents in the current session — track which worktree names/branches were spawned
2. Never use --force — if git worktree remove warns about modified files, STOP and ask the user
3. When in doubt, ask — “I see a worktree at .claude/worktrees/audit-items. Was this created by a previous session? Should I leave it alone?”

Recovery Steps (When Damage Is Done)

# 1. Recover the branch (commits are still in the object store)
git branch <branch-name> <sha-from-worktree-list-output>

# 2. Recreate the worktree
git worktree add .claude/worktrees/<name> <branch-name>

# 3. Uncommitted changes are GONE — no recovery possible
# The working directory was deleted, and uncommitted changes
# are not stored in git's object store

Prevention

For Agent Leaders

• Do NOT clean up .claude/worktrees/ — the Task tool handles agent worktree lifecycle
• git worktree list is informational — listing worktrees does not grant permission to remove them
• --force on remove is a destructive action — always requires explicit user confirmation
• The safety check (“contains modified or untracked files”) exists for a reason — respect it

For the System

• Agent worktrees should use a naming convention that distinguishes them from user worktrees (e.g., agent-<team>-<name> prefix)
• The Task tool’s auto-cleanup makes manual worktree removal unnecessary

Warning Signs

• git worktree list shows worktrees you don’t recognize
• git worktree remove (without --force) warns about modified files
• A worktree branch name doesn’t match any agent you spawned

First Encountered

2026-02-22 — Code audit remediation session. Leader attempted to clean up .claude/worktrees/audit-items after completing the audit team’s work. The worktree was from a previous session implementing Linear epics. Branch recovered at b6d7618, but any uncommitted working directory changes were lost.