Two Claude Code sessions can share the same worktree path and silently clobber each other's uncommitted work

Summary

Two separate Claude Code sessions (started via the "start with worktree" suggested-task chip in the same host session) ended up pointed at the identical .claude/worktrees/<name> directory instead of each getting its own. Git worktrees have no locking between processes, so when one session ran git checkout/a branch switch in that shared folder, it silently overwrote the working tree and wiped the other session's uncommitted edits — with no error, no warning, and a completely clean-looking git status/git log afterward.

Impact

This happened twice in one sitting on the same machine, with three sessions running concurrently:

1. An in-progress feature's uncommitted work-in-progress was silently clobbered.
2. Minutes later, a bugfix was clobbered seconds after being written, before it could even be git added.

Both times, the aftermath state gave no indication anything was lost — no conflict markers, no stash, no error. The only tell was that the file content on disk didn't match what had just been written. This is a dangerous failure mode: silent, undetectable data loss under normal, expected usage (multiple background tasks started from suggested-task chips in the same working session).

Reproduction context

• Host session spawned two background tasks via the suggested-task chip ("start in a fresh worktree with one click").
• Both ended up assigned the same worktree path (clever-jepsen-93ab22 in this case).
• Confirmed via git worktree list that the path was shared between what should have been two independent worktrees.

Suspected root cause (unconfirmed — needs someone with harness visibility)

Something in how a worktree name/path gets assigned when the button is pressed can produce the same name for two different requests. I don't have visibility into the actual allocation logic, so I can't confirm the exact mechanism, but two candidate failure modes:

• Weak/low-entropy name generation (if the name is drawn from a bounded pool, e.g. adjective+noun+short-hex) — a birthday-paradox-style collision by chance.
• A check-then-create race — if the button checks "does a worktree for this already exist?" and two near-simultaneous requests both see "no" before either finishes creating one, they could both proceed to create/reuse the same path. This wouldn't be fixed by more unique naming alone; it would need locking/atomicity around the check-then-create step.

Suggested mitigation (workaround, not a fix)

For now, a session that finds itself possibly sharing a worktree can call EnterWorktree explicitly to get a genuinely dedicated directory, then commit any in-progress work immediately rather than leaving it uncommitted for any length of time. This is a workaround, not a fix — it relies on the session remembering to do this, which won't happen by default.

What would help

• Worktree paths/names should be guaranteed collision-free (e.g. include a high-resolution timestamp + monotonic counter/PID, or a real UUID) if the root cause is generation entropy.
• If the root cause is a check-then-create race, the allocation should be made atomic (e.g. mkdir-based locking, or a server-side reservation) rather than relying on a name being unique after the fact.
• Ideally, detect and hard-fail loudly if two sessions ever do end up pointed at the same worktree path, rather than allowing silent overwrite on git checkout.