Agent tool's isolation:'worktree' binds the worktree's base repo to the caller's Bash cwd at dispatch time, not the target repo

Summary

When calling the Agent tool with isolation: 'worktree', the isolated worktree's base repository appears to be determined by the dispatching session's current Bash-tool working directory at the moment Agent is called — not by anything in the prompt, and there is no parameter on the tool to specify the target repo explicitly. This causes silent cross-repo mis-dispatch whenever the caller works across multiple git repos in one session (a very common pattern for a multi-repo monorepo-adjacent codebase).

Reproduction (observed this session, 7 Agent(isolation:'worktree') calls across a multi-repo task)

1. Sent 4 Agent(isolation:'worktree') calls in a single batched message (one message, multiple tool_use blocks), targeting 4 different repos (A, B, C, D). The Bash cwd at send time was repo C.

• Result: all four landed with their isolated worktree rooted in repo A (not C, not their individually-intended targets). Two of the four happened to actually need repo A, so those "worked" by coincidence; the other two (needing B and D) failed immediately — each correctly detected the mismatch via git rev-parse --show-toplevel and self-reported rather than attempting a -C/GIT_DIR/GIT_WORK_TREE workaround (which the sandbox also independently blocked when the agents tried, as a defense-in-depth check).

1. Retried the repo-B task alone: ran cd <repo B> via Bash, then immediately (no other tool call in between) issued a single Agent(isolation:'worktree') call.

• Result: correctly landed in repo B.

1. Immediately retried the repo-D task alone, but issued right after the repo-B retry above with no intervening cd.

• Result: incorrectly landed in repo B again (inherited from the previous dispatch's cwd, not the cwd at the time of this call — actually in this case it was the same cwd, since nothing changed it, confirming cwd-at-call-time is the mechanism, and it persists across calls until explicitly changed).

1. Retried repo D a third time, with cd <repo D> issued immediately before, single call, nothing in between.

• Result: correctly landed in repo D.

Conclusion

The base repo for isolation: 'worktree' is bound to whatever directory the orchestrating session's Bash tool was last cd'd to, evaluated at Agent-call time, and this state is NOT scoped per-call or per-batch — it's ambient session state that leaks across unrelated tool calls, including across calls sent in the same message/batch (which all appear to share one cwd snapshot rather than each specifying their own).

This makes isolation: 'worktree' unsafe to use for cross-repo work without an extremely fragile discipline: never batch multiple isolated dispatches targeting different repos, and always cd to the exact target repo immediately before each single dispatch with zero other tool calls in between. Any orchestration pattern that fans out N agents across N repos in parallel (a natural use case for background agent dispatch) is currently broken by this.

Suggested fix

Add an explicit repo/path parameter to Agent (e.g. cwd or repoPath) that determines the isolated worktree's base repository, independent of the dispatching session's own shell state. This removes the ambient-state footgun entirely and makes cross-repo parallel dispatch safe to batch.

Environment

• Claude Code CLI, multi-repo local development environment (several sibling git repos under one parent directory)
• Observed via the Agent tool with isolation: 'worktree', subagent_type: 'general-purpose', dispatched in both batched and single-call forms in the same session