Agent isolation:"worktree" — concurrent dispatches sometimes execute early commands in the parent worktree, not the isolated one

Summary

Agent tool calls with isolation: "worktree" appear to sometimes execute the
agent's first shell command(s) against the wrong working directory (the
parent/principal session's worktree) rather than the newly-created isolated
worktree, when several isolation: "worktree" agents are dispatched
concurrently. The agent's later commands in the same session then correctly
resolve to its own isolated worktree, and its own final self-report/footer
(worktreePath:/worktreeBranch:) can look entirely correct — but a stray
prefix of git-mutating commands has already landed in the shared parent
worktree.

What we observed

During an autonomous multi-agent release orchestration (Grimoire-framework
Noir paradigm, 14 Agent(isolation:"worktree") dispatches across 3 batches in
one release), the parent/orchestrator session's own principal worktree showed
a chain of 5 sequential git branch -m <name> events in its reflog — one per
dispatched agent in that batch, each renaming the shared checked-out branch,
each overwriting the previous rename. Each dispatch prompt instructed the
agent: "first, rename your current branch to <branch-name>" as its very
first action after landing in its own worktree.

Cross-checking each agent's own dedicated worktree afterward:

• 3 of 7 agents in that batch ended up with a correctly-renamed branch and

their real work correctly committed, entirely inside their own isolated
worktree (no visible effect from the above).

• 1 agent's own worktree never had its branch renamed at all (still sitting

on the default worktree-agent-<id> placeholder name) — but its actual
work was committed correctly inside its own worktree, under that
unrenamed branch. Its rename command appears to be the one that hit the
parent worktree's branch instead.

• 1 agent (the most severe case) had its entire final commit — not just the

rename — land on the parent/principal worktree's checked-out branch. Its own
dedicated worktree was left completely untouched at the original base
commit, with no commits of its own. Its self-reported
worktreePath:/worktreeBranch: footer did not accurately reflect what had
happened.

Separately (and possibly related, possibly a distinct issue), several later
agents in subsequent, less-concurrent batches reported catching their own
worktree rooted at a stale/wrong base commit (an old ancestor far behind the
intended integration branch's live tip at dispatch time) before making any
commits, and self-corrected by re-rooting in place.

Why this looks like a race, not a one-off

• The affected agents' substantive work (file edits, git commit) mostly

still landed correctly in their own isolated worktrees, even when an early
command (the rename) did not — suggesting the misdirection is transient,
present only in the first tool call(s) issued right after worktree
creation, and resolves itself shortly after.

• The one full-cross-contamination case is consistent with the same

transient window simply lasting long enough to also catch that agent's
final commit, rather than a structurally different failure mode.

• This only appeared with several isolation:"worktree" agents dispatched

in the same batch (i.e., concurrently) — not with single, sequential
dispatches earlier/later in the same session.

Impact

• Silent branch/commit corruption in the parent session's checked-out

branch — recoverable via git reflog + manual branch renaming (which is
how we recovered here, with no data loss), but only detectable by manually
auditing the parent worktree's reflog and every dispatched worktree's
actual branch/HEAD state — the agent's own "done" report and the
worktreePath:/worktreeBranch: footer are not sufficient signals to
detect it.

• Any workflow that trusts an isolated agent's self-report of having stayed

in its own worktree could silently merge or lose work incorrectly.

Ask

1. Is isolation: "worktree" provisioning (creating the worktree, attaching

the spawned agent's shell cwd to it) synchronous with the agent's first
tool call, or is there a window where a fresh agent's Bash cwd could
still resolve to the parent session's directory? A race here would
explain everything above.

1. If a race exists, could the Agent tool result reliably surface (or the

harness detect) when a spawned agent's commands executed outside its
assigned worktree, rather than relying on the agent's own self-report?

Happy to provide more detail (this was reconstructed from git reflog and
per-worktree branch/HEAD inspection after the fact, not captured live with
tracing) if useful.