A worktree-isolated agent's own sub-dispatched Agent calls inherit its worktree/repo, regardless of the declared target repo

Summary

When an already worktree-isolated agent (Agent(isolation:"worktree")) itself spawns a further sub-agent via a second Agent(...) call targeting a different repository, the sub-dispatched agent gets pinned to the PARENT agent's worktree/repo, regardless of the sub-dispatch's declared target repo or instructions — even when the sub-dispatch explicitly requests isolation:"worktree" against the different repo, and even when it requests no isolation at all and is simply instructed to cd into the target repo path.

Repro steps

1. From a top-level session, dispatch Agent(isolation:"worktree") against repo A. The harness auto-creates a worktree in repo A for this agent.
2. From inside that agent (not the top-level session), dispatch a second Agent(...) call, instructing it to do work in repo B (a sibling repo, not a subdirectory of A) — tried in two variants:

• Variant 1: sub-dispatch with isolation:"worktree" explicitly set, expecting the harness to create a fresh worktree in repo B.
• Variant 2: sub-dispatch with no isolation flag, with the task instructions explicitly telling the sub-agent to cd into repo B's path directly.

Expected

At least one of the two variants should let the sub-dispatched agent actually operate against repo B.

Actual

Both variants hit the identical blocker: the sub-dispatched agent is hard-pinned to the PARENT's repo A worktree context. Every git operation targeting repo B's path (cd <repo B path> && git ... and git -C <repo B path> ... both tried) is refused by the sandbox with an isolation error to the effect of "a worktree-isolated agent's git operations must target its own worktree."

EnterWorktree does not help as a workaround here either — it refuses to create or switch to a worktree of a different repository from a cwd-pinned sub-agent.

There is no exposed cwd/working-directory parameter on the Agent dispatch call itself that a calling (already-isolated) agent could use to correctly root a sub-dispatch in a different repo.

Both sub-dispatched agents in the reproduction behaved correctly given the constraint — neither attempted a workaround or bypass; both performed only read-only diagnostic probes (ls, git status, git -C ... status), touched zero files or git state, and reported the blocker clearly rather than retrying in a loop.

Hypothesis (unconfirmed)

Isolation/worktree pinning for a spawned Agent call may be inherited transitively from the CALLING agent's own process/session state, rather than being freshly derived at dispatch time from either (a) the calling agent's own current cwd, or (b) any cwd-equivalent instruction/parameter the caller supplies for the sub-dispatch. If that's correct, it would mean any agent that is itself worktree-isolated can never successfully dispatch a properly-scoped sub-agent into a different repository, regardless of what isolation mode or cwd instructions are given to the sub-dispatch.

Workaround found

The calling context needs to be a session that is not itself worktree-isolated (e.g. a top-level/supervising session, which can cd freely between sibling repo checkouts) to reliably dispatch a correctly-rooted Agent call into a different repo. A worktree-isolated agent should not be relied on to sub-dispatch cross-repo work — that has to happen one level up, in whatever non-isolated context actually launched it.

Relationship to a related, distinct issue

This looks related to but distinct from the EnterWorktree desync behavior described in the linked issue below — that one is about a mid-session switch desyncing an already-running agent's own Bash tool from its actual worktree; this one is about a newly spawned sub-agent being pinned to the wrong repo entirely from the moment it starts, which looks like a dispatch-time inheritance issue rather than a mid-session state desync. Related: https://github.com/anthropics/claude-code/issues/92867

Impact

Any orchestration pattern that delegates "figure out a cross-repo task, dispatch whatever sub-work is needed" to a single implementer agent will silently fail on the cross-repo half whenever that implementer is itself worktree-isolated. This is worth documenting (or fixing) before designing multi-repo task prompts that assume a dispatched agent can freely sub-dispatch further agents into other repos.