Parallel isolation:"worktree" agents commit to each other's branches and mutate the main working tree (stash/HEAD), inconsistently across a batch

Problem

When several agents are dispatched in one message with isolation: "worktree", a subset of them do not stay confined to their own worktree — instead they operate against the parent (main) repository's working tree and refs. The result is not the "lock contention → lost work" failure of #55724, but the opposite: the agents succeed, yet their commits and git side-effects land in the wrong place:

• One agent's commit was applied to another agent's feature branch (a test(bl-274): … commit ended up sandwiched inside the branch/PR belonging to a different item, contaminating that PR's diff).
• Agents created git stash entries in the main repository (stash@{n}: On feat-bl-251-…, On feat-bl-282-…), i.e. they were manipulating the parent repo's stash stack, not an isolated one.
• Agents reported "the worktree was fighting HEAD resets from concurrent background agents" and resorted to git cherry-pick to recover their own commits from a peer's branch.
• The parent repo's uncommitted working-tree changes were stashed/reverted out from under the user by a child agent.

In the same batch, 2 of 5 agents got correct isolated worktrees (.claude/worktrees/…, clean single-item PRs); the other 3 exhibited the contamination above. So the isolation is applied inconsistently across a concurrent batch rather than failing uniformly.

Reproduction

1. On main/master with a clean-ish working tree (one unrelated uncommitted file present), send one message containing 5 Agent calls, each isolation: "worktree", each instructed to create a branch feat-<x>, commit several times, and open a PR.
2. Let them run concurrently.
3. Observe after they finish:

• git worktree list shows dedicated worktrees for only some of the agents.
• git branch -vv: at least one feature branch contains a commit authored for a different agent's item.
• git stash list shows entries created by the agents against the parent repo.
• A pre-existing uncommitted change in the parent working tree has been stashed/reverted.

Expected

Each isolation: "worktree" agent should be fully confined to its own worktree + branch: its git add/commit/stash/reset/checkout must never touch the parent repo's working tree, stash stack, HEAD, or another agent's branch — regardless of how many run concurrently.

Impact

• PR contamination: an item's PR silently includes another item's commit (had to git rebase --onto to drop the stray commit and force-push to clean the PR).
• Main-repo pollution: orphaned stashes + reverted user WIP in the parent checkout.
• Undermines the core promise of isolation: "worktree" for parallel/orchestrator workflows, forcing a fall back to strictly serial (one-at-a-time) agent execution.

Related

• #55724 (closed) — same root (concurrent agents sharing the parent .git/), but that report is about lock-contention failing agents and losing work; this is agents succeeding while writing to the wrong tree/branch. Different observable symptom, likely same underlying shared-.git/ cause.
• #77671 — isolation:"worktree" base-ref behavior.
• #47266 (closed) — git config lock race under parallel worktree agents.

Environment

• Claude Code: 2.1.220
• git: 2.45.2
• OS: Darwin 25.5.0 (macOS, arm64)
• Model: Opus 4.8
• Scenario: orchestrator agent fanning out 5 concurrent isolation:"worktree" implementation subagents in a single message.