[FEATURE] Add cwd parameter to Task tool for setting subagent working directory (to support Git worktrees)

@YPares this is similar to something I was going to request - are you also having issues with subagents writing in worktree directories? I have a prompt like the following:

Review @ux_changes.md - I want to have several subagents spin up separate git worktrees and execute these different tasks. The results should be committed in draft pull requests that can be reviewed.

I attempted updating settings.json with the following:

{
  "permissions": {
    "additionalDirectories": [
      "../worktree-prefix-*"
    ],
}

Do you have something like this working, or is a cwd param your proposed solution to get this working?

@AwolDes Indeed you can work around by adding your other worktrees as additionally allowed directories, but my proposal was indeed to add a new cwd param that the top-level agent could use to streamline this (notably if the top-level agent creates worktrees dynamically to span several sub-agents in parallel to work on different tasks which you want to be committed separately).

Having just a cwd param instead of a deeper git worktree integration would fix the biggest part of the problem, and is also more general:

• in a monorepo, the sub agents can be directed to work on a subfolder (instead of a separate worktree)
• makes it compatible with other VCSs like JJ (which I use), which has its own solution for worktrees but besides that is still git-compatible

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

If the issue is still occurring, please comment to let us know.

Well, yes it is ^^

Furthermore, a sub-agent could automatically load the .claude context of its target directory to discover available skills and MCP configurations, etc.

Related: #31940 extends this request to also cover additionalDirectories per subagent (not just cwd).

The use case driving that issue: a scheduling agent where the orchestrator spawns per-user subagents to read private data from users/{userId}/. Each subagent needs access to its own user's directory plus a shared threads/ directory, but must be blocked from other users' directories. cwd alone doesn't solve this — you also need a way to declare which additional directories outside cwd a subagent is allowed to read.

Current workaround requires PreToolUse hooks with union-based enforcement, which breaks down when two user-subagents run in parallel (the union of their allowed dirs means cross-access becomes possible). With both cwd and additionalDirectories on AgentDefinition/frontmatter, this would be declarative and correct.

Also related: #31939 — PreToolUse hook input missing agent_id, which is the other half of the same isolation problem.

Same problem here. We're orchestrating agents across multiple service repos from a parent directory (e.g. schema changes in one repo, consumer changes in another).

isolation: "worktree" fails because CWD isn't a git repo, and even with WorktreeCreate hooks there's no way to pass per-invocation context about which repo to target. The hook gets { worktree_path, session_id, cwd } — no room for the agent to say "I want a worktree of repo X."

A cwd parameter would solve this cleanly. The orchestrating agent knows which repo it wants — it just has no way to tell Claude Code.

I'm in desperate need of this as well. Not sure how else one operates on a single git repo with multiple agents at once.

+1 from a real-world use case that this would solve.

Setup: monorepo with git worktrees for parallel topic branches. We use a project-level MEMORY.md rule that forbids git -C <path> and compound cd <path> && git ... patterns (the latter is also blocked by Claude Code's built-in bare-repo injection protection). Subagents need to do git operations from inside specific worktrees.

What goes wrong: every workaround a subagent could try is unavailable:

• cd worktree/X then git status as separate Bash calls — fails because subagent CWD doesn't persist between Bash calls (this is the bug at #33576, now locked)
• cd X && git status — blocked by the cd && git security check
• git -C X status — blocked by user preference
• bash -c 'cd X && git ...' — also blocked (subshell variant of compound)
• GIT_WORK_TREE=X git ... — also blocked

Net effect: subagents can write code, run tests, and use Read/Edit/Write fine, but cannot commit or push from a worktree. The main thread takes them across the line every time. In a single 8-hour session this week we hit it 5 times across 5 different subagent dispatches; the manual handoff cost ~30% of the session's wall-clock.

A cwd: parameter on the Task tool would resolve the entire class of problem cleanly — you specify the worktree once at dispatch, the subagent's Bash tool inherits it, and none of the security restrictions need to be relaxed.

Strong +1 — worth flagging the Jujutsu (jj) workspace case explicitly, since it's adjacent to but distinct from git worktrees.

For jj-only repos, isolation: "worktree" is a non-starter: it creates a git worktree, which jj can't see or clean (orphan teardown needs raw git worktree remove). jj's native equivalent is jj workspace add <path> — but there's no way to point a subagent at one without a cwd/workdir param. This is exactly the unblock: pre-create a jj workspace, dispatch with cwd set to it, reap with jj workspace forget — fully jj-native, zero git worktrees.

One caveat that makes it a two-part fix: a cwd param only delivers real isolation if the agent's path resolution honors it. #62590 reports the exact leak — inside a jj workspace, @-file refs still resolve to the parent git repo root. So #12748 + #62590 together = working jj-workspace subagent isolation. Worth tracking as a pair.

I'm also heavily using this in mono repos. I have an orchestration session behaving as a PO advocate and divvying out work to sub sessions. They have their own CLAUDE.md and agent and sub agent definitions. It works very well, but is fragile. Right now I'm fixing an issue in my harness causes by sub agents being background-ed by default now. I would much prefer if this is just supported functionality.

I'm using rust and I started out running subagents in ephemeral harness-created worktrees. But freshly-created worktrees have cold target dirs, and it turns out that sccache won't get cache hits on ephemeral worktrees either for abstruse reasons that SCCACHE_BASEDIRS doesn't solve.

So claude and I rolled a setup with a pool of persistent worktrees with warm target dirs and sccache cacheability from having the same path over time. And I have subagents running in those, but it's been permission-check hell. Fable just pointed me here, so a big 👍 from me on this one.

Additional context: I ended up _very reluctantly_ abandoning jj/jujutsu for now, as, even with a fantastic guide for LLMs to use jj (https://gist.github.com/pmarreck/03c006fb2f5b70dcc35bdadb2c101a12), the impedance mismatch between jj's way of doing things, colocated git's way of doing things and the giant mass of git training data that LLM's ALWAYS default to (we can call it... LLMomentum... and frankly, I'm not keen on that aspect), caused a consistent stream of screwups, confusing detached HEADs, lost/re-done work, etc. etc. etc.

For my use case, using a WorktreeCreate hook with isolation: "worktree" works for me now. I don't care which specific worktree subagents end up in, I just want each subagent to get a worktree slot with a warm target dir (to speed up rust compiles). I tried using a WorktreeCreate hook on July 21st, but it didn't work in my hands then - for subagents in a hook-supplied worktree, the Write and Edit tools rejected edits in the worktree. That's changed since - possibly with the v2.1.222 release (2026-08-04), which has this in its release notes:

Fixed worktree-isolated sessions and their subagents being able to run destructive git commands against the main checkout; isolation now applies to file edits and Bash in every session type.

My reading of that is that Write/Edit and git commands used to have divergent isolation behavior in worktree-isolated sessions, and now they're consistent. So I've adopted the hook and it seems to be working fine. Maybe it works for the jj use case now too? I haven't tried.

I still think it makes sense to add a cwd parameter to the Agent tool (renamed from Task, I believe); there's just too many reasons you'd want it.

I also experimented with passing a path to the EnterWorktree tool, but agents get a refusal:

Cannot enter worktree: the current working directory <my repo root> is the repository root, not an isolated worktree — switching is only available to sessions whose working directory is inside a worktree of this repository.

I don't know why the harness would refuse that, but it's what I've run into.

For those of you who want to direct subagents into a specific worktree, I haven't seen a good way to do it. Claude suggested that the spawning agent could write something that the hook then reads. Sounds fragile and rube-goldbergian but if you have a single spawning agent that's spawning subagents one at a time, maybe it works?