Subagent Bash cwd resets to another subagent's worktree, with no cwd param to pin it

Summary

In a subagent, the Bash tool's working directory resets between calls — and the directory it resets to is not the subagent's launch directory, the parent session's directory, or the project root. In a session running several concurrent subagents, one subagent's Bash calls landed in a different subagent's git worktree.

Combined with the Agent tool having no cwd parameter (#12748), there is no way to pin a subagent to a directory: not at spawn time (no parameter), and not at run time (cd does not persist). Any subagent instructed to work in a specific checkout can silently operate on a different one.

This is related to but distinct from #76708, which reports non-persistence in a main session with a reset to the session default. The subagent case is worse in two ways: the reset target is not the default but an apparently arbitrary directory belonging to a sibling agent, and there is no spawn-time parameter to work around it.

Environment

• Claude Code version: 2.1.235
• OS: Windows 11 Pro 26200, Git Bash
• Repo with ~20 git worktree checkouts under <repo>/.worktrees/*, several subagents working concurrently in different worktrees
• Subagents spawned via the Agent tool with subagent_type: "general-purpose", no isolation set

What happened

Six subagents were spawned from a session whose own Bash cwd was the repo root. Each was told, in its prompt, to cd to its own worktree first.

1. Subagent A (target <repo>/.worktrees/1073-docs) ran cd <repo>/.worktrees/1073-docs as its own Bash call — no error — then git merge <branch> --no-edit as the next call. The cd had not taken effect, so the merge ran against the root checkout, fast-forwarding the root's main onto an unmerged feature branch. Working tree was clean, so nothing was lost, but main in the primary checkout was left pointing at unreviewed work; a subsequent git push from root would have published it.

1. Subagent B (target <repo>/.worktrees/1078-member-tiles) was later told to check pwd before every git command. It reported:

• pwd → /h/source/Humans/.worktrees/1073-docs — subagent A's worktree, neither its own target nor the root nor the parent session's cwd
• cd <repo>/.worktrees/1078-member-tiles as a standalone call → no output, appears to succeed
• pwd in the next call → still /h/source/Humans/.worktrees/1073-docs

Had it not checked, its git commit/git push would have run inside another agent's active worktree.

1. A third subagent independently reported pwd returning the repo root regardless of any prior cd.

Subagent B quoted its own system prompt back: "Agent threads always have their cwd reset between bash calls, as a result please only use absolute file paths." That guidance is fine for file tools, which take absolute paths — but git has no absolute-path equivalent that is not itself a workaround (git -C, GIT_DIR/GIT_WORK_TREE), and both are commonly barred by project convention because they defeat permission-allowlist prefixes.

Why the workarounds don't hold

• cd X && cmd in one call — works, but compound commands are exactly what #76708 shows delivering stale cwd to hooks, and many setups block the pattern outright.
• git -C / GIT_DIR + GIT_WORK_TREE — retargets git away from the working directory and bypasses Bash(git ...:*) permission prefixes, forcing a classifier round-trip per call.
• isolation: "worktree" — creates a fresh worktree branched off the default branch. No help when the agent must work on an existing branch already checked out elsewhere, which is the normal case for fixing an open PR.
• EnterWorktree — session-scoped; per #84493 the last caller silently repoints every other agent in the session.

The reliable mitigation we landed on is to forbid subagents from running git at all and have the orchestrator perform every git operation. That works, but it means multi-worktree fan-out cannot delegate the one operation that most needs the right directory.

Expected behavior

Any one of these would close the hole:

• The Agent tool accepts a cwd parameter that pins the subagent's Bash working directory for its lifetime (this is #12748), and that pin survives across Bash calls.
• Failing a parameter, the per-call reset target is deterministic and documented — the subagent's launch directory or the parent session's cwd. Resetting into a sibling agent's directory is the specific behavior that makes this dangerous rather than merely inconvenient.
• A standalone cd that does not persist should say so in the tool result, the way the main-session case reportedly emits Shell cwd was reset to <default>. Silent no-op success is what let case 1 through.

Repro sketch

1. Create two worktrees: git worktree add .worktrees/a and git worktree add .worktrees/b.
2. Spawn two concurrent subagents via the Agent tool, telling each to cd into its own worktree.
3. Have each run pwd as a standalone Bash call, then cd <its worktree> as a second call, then pwd again as a third.
4. Observe that pwd does not track the cd, and that at least one agent reports a directory belonging to the other agent or to the root checkout.

Related

• #12748 — feature request for a cwd parameter on the Task/Agent tool (the missing spawn-time half)
• #76708 — Bash cwd not persisting in a main session, resetting to the session default
• #84493, #82737, #87643 — worktree/isolation binding being session-scoped or pinned to the wrong tree