Worktree pool assigns relaunched sessions to the wrong worktree (95% of sessions measured), and can discard uncommitted work

Environment

• Claude Code desktop app on Windows 11
• Multiple parallel sessions on one repository, using the app's automatic worktree feature
• Repository has ~44 pooled worktrees

Summary

When a session is reopened from a background-task chip (a "continue this work" card),
the app places it in a worktree that does not correspond to the work it was given.
The session identity and title are always correct — only the working directory is wrong.

Separately, and more seriously, the pool has been observed resetting a worktree that
contained uncommitted changes in order to recycle it, permanently destroying that work.

Evidence (measured, not estimated)

Scanned 1,764 session transcripts on this machine, covering 2026-08-26 to 2026-09-02.
44 distinct sessions were opened from chips carrying an expected-worktree path.
Comparison was between the expected path recorded at spawn time and the session's own
recorded working directory, normalised for slash direction and case.

| Result | Sessions |
|---|---|
| Landed in the wrong worktree | 42 / 44 (95.5%) |
| Landed correctly | 2 / 44 |

Per day:

| Date | Sessions opened | Wrong worktree |
|---|---|---|
| 2026-08-27 | 2 | 2 |
| 2026-08-28 | 6 | 5 |
| 2026-08-29 | 9 | 9 |
| 2026-08-30 | 8 | 7 |
| 2026-08-31 | 15 | 15 |
| 2026-09-02 | 1 | 1 |

These are not path-formatting artifacts. Example: expected
.../worktrees/clever-rosalind-ef53a2, actual .../worktrees/elegant-euler-7d5da0 —
entirely different worktrees on unrelated branches.

Corroborating detail: 11 of the 44 sessions have their transcript written into two
different project directories (the pre- and post-relocation path), which is itself a
fingerprint of the relocation.

Impact

1. Work performed against the wrong code. In one of the 44 sessions the model never

detected the mismatch and completed an entire investigation in an unrelated worktree.

1. Folder names, folders and branches drift apart. On this machine a worktree named

serene-kalam-7b61dc currently holds an unrelated branch, while the branch actually
named claude/serene-kalam-7b61dc is checked out in a differently-named folder.
A session told to return to "its" folder therefore lands on someone else's code.

1. Data loss. On 2026-08-03, closing a session produced this log sequence within two

seconds, destroying four files of uncommitted work that existed only in that worktree:

``
16:40:03 LocalSessions.archive: sessionId=local_c687c401...
16:40:03 Cleaning up worktree checkin-form-crm-deps-ce28ed for session local_c687c401...
16:40:04 [WorktreePool] Reset dirty worktree checkin-form-crm-deps-ce28ed to clean for pooling
16:40:05 [WorktreePool] Released worktree checkin-form-crm-deps-ce28ed to pool
16:44:33 [rebindWorktree] Rebound ... to local_d3d96b55... on branch claude/distracted-kowalevski-01f211
``

Confirmed unrecoverable: file timestamps matched the wipe to the second, and nothing
was present in any stash, reflog, or dangling object.

1. Reassignment during active use. On 2026-08-19 a worktree was repointed to a

different branch while a session was mid-way through a 24-minute test run in it,
producing incoherent failures (tracebacks referencing files not present on disk).

Observed mechanism, from %APPDATA%\Claude\logs\main*.log

1. On session close the app logs Cleaning up worktree <slot> — deleting the checkout and

unregistering it — but then logs [WorktreePool] Released worktree <slot> to pool, so the
pool still lists the slot as reusable.

1. A later session gets [rebindWorktree] Rebound <slot> ... on branch claude/<x> with no

fresh git worktree add. The folder is recreated but has no .git file, so git commands
run inside it fall through to the shared repository root, and the session's branch is
checked out on the root.

1. Once the root holds such a branch, later git worktree add calls for it fail with

"already used by worktree at <root>", and the app logs falling back to origin repo —
running that session directly at the shared root. This is self-perpetuating.

A newer variant also occurs where the app does run a real git worktree add and the
worktree is properly registered — it is simply pointed at the wrong branch. So the missing
registration is not the whole cause.

Windows aggravator: cleanup can fail partway when a preview server or terminal holds files
open, leaving partially-deleted, unregistered folders behind.

Suggested direction

Bind a reopened session to its branch, which is unique and stable, rather than to a
worktree folder path, which is a recycled slot whose contents change. Additionally, never
reset a worktree that has uncommitted changes in order to pool it — refuse to recycle it,
or preserve the changes first.

What was ruled out

• Not a path-format or slash-direction mismatch (normalisation was applied before comparing).
• Not misdelivery of the task: in every case examined by hand, the session's own title

matched the work it was given.