Worktree isolation: likely branch name collision across sessions causes stale results

Summary

When running code-simplifier:code-simplifier agents with isolation: "worktree" across two separate sessions, all four agents in the second session reported making changes that exactly matched the first session's (already-committed) work. No agent reported finding nothing to do. No worktree branches appeared in git reflog or git branch -a after the run.

The most likely cause is deterministic worktree branch naming colliding across sessions, causing second-pass agents to pick up stale state from the first pass rather than working from a fresh checkout of HEAD.

Reproduction

Session 1 (first pass)

Launched 4 parallel code-simplifier:code-simplifier agents with isolation: "worktree" against frontend source files. Agents made real changes, which were committed to main across several commits. Worktrees were automatically cleaned up.

Session 2 (second pass, same repo, new conversation)

Launched 4 parallel code-simplifier:code-simplifier agents with isolation: "worktree" against the same file groups, same agent type, same prompts. All four agents reported making specific changes — but every reported change was already present on main from Session 1. Zero agents reported "nothing to do."

Post-run investigation

• git worktree list — only main worktree
• git branch -a | grep worktree — no worktree branches
• git reflog --all --since="2 hours ago" — no worktree branch creation/checkout activity
• .claude/worktrees/ directory existed (born during Session 1, modified during Session 2) but was empty
• .git/worktrees/ directory did not exist
• git fsck --unreachable — no worktree-related commits, only old stash objects
• All evidence of what happened inside the worktrees was destroyed by automatic cleanup

Expected behavior

Each agent should get a fresh checkout from current HEAD. If the code is already in the target state, agents should report that no changes were needed.

Actual behavior

All four agents returned reports describing changes that matched Session 1's work exactly — as if they were operating on pre-Session-1 code or returning cached/stale results from Session 1's worktree branches.

Root cause hypothesis

Three documented issues combine to make this possible:

1. Deterministic branch naming (#27749): Branch names are hardcoded as worktree-agent-{hash}. If the hash is derived from agent type rather than per-invocation randomness, running the same agent type twice produces the same branch name.

1. Stale worktree persistence (#26725): Worktree state from previous sessions can persist with no garbage collection at session start.

1. Automatic cleanup destroys evidence (#29110): After the run, branches and worktree directories are silently removed, making it impossible to diagnose what happened post-hoc.

The combination means: Session 1 creates worktree branches, makes changes, commits to main, but branch metadata or naming state persists. Session 2 reuses the same branch names, picks up stale state, returns first-pass results. Cleanup erases the trail.

Impact

• Silent incorrect results — agents report work they didn't do (or re-did from stale state)
• No way to detect the problem without manually verifying every reported change
• No way to diagnose after the fact — cleanup removes all forensic evidence
• Affects any workflow that runs the same agent type with worktree isolation more than once

Suggested fixes

• Use per-invocation random suffixes in worktree branch names (e.g., worktree-code-simplifier-a8f3c2) to prevent cross-session collisions
• GC stale worktrees at session start — prune any worktree branches/directories left over from previous sessions before creating new ones
• Don't auto-delete worktree branches — or at minimum, make cleanup opt-in. The current behavior prioritizes repo tidiness over auditability, which is the wrong tradeoff for a tool that emphasizes careful, reversible actions

Environment

• Claude Code with Opus 4.6 (1M context)
• Linux 6.17.0-1008-nvidia
• Git 2.47.2 (estimated)

Related issues

• #27749 — request for custom worktree branch naming
• #26725 — stale worktrees never cleaned up
• #29110 — parallel agent worktree data loss