Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Subagent Bash tool CWD does not inherit from Task launch context AND every workaround is blocked by security checks [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#53383•Fetched 2026-04-26 05:17:15
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
yohananyohanan
Participants
github-actions[bot]github-actions[bot]yohananyohanan
Timeline (top)
labeled ×4commented ×1

Fix Action

Fix / Workaround

Why this is more than a "use the workarounds" issue

All standard workarounds are blocked:

WorkaroundWhy it doesn't work
cd X then git Y as separate callsCWD doesn't persist between subagent Bash calls (this bug)
cd X && git Y (compound)Blocked by Claude Code's bare-repository injection protection
bash -c 'cd X && git Y'Same blocker (subshell variant)
git -C X YBlocked by many teams' shell-safety rules
GIT_WORK_TREE=X git Y env varsSame — env vars change git's behavior subtly
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and the closest match (#33576) was closed-for-inactivity and locked, with the auto-close note explicitly directing users to file a new issue if still relevant.
  • This is a single bug report.
  • I am using the latest version of Claude Code.

What's Wrong?

Same bug reported in #33576 (now locked) and #35023 (closed as duplicate of #33576): subagents launched via the Task tool have their Bash tool CWD reset between calls, defaulting away from the parent session's working directory. Re-filing per the auto-close instruction since the bug remains active in current Claude Code versions and is still actively biting users.

Why this is more than a "use the workarounds" issue

All standard workarounds are blocked:

WorkaroundWhy it doesn't work
cd X then git Y as separate callsCWD doesn't persist between subagent Bash calls (this bug)
cd X && git Y (compound)Blocked by Claude Code's bare-repository injection protection
bash -c 'cd X && git Y'Same blocker (subshell variant)
git -C X YBlocked by many teams' shell-safety rules
GIT_WORK_TREE=X git Y env varsSame — env vars change git's behavior subtly

The result is subagents that can write code, run tests, and use Read/Edit/Write fine, but cannot do any git operations in a non-default directory. Every multi-worktree workflow loses its agent productivity.

Reproduction

  1. From a project root, create a git worktree at ../worktree/test.
  2. Launch a subagent (any specialist or general-purpose) and instruct it to commit a change to a file in ../worktree/test.
  3. Observe: subagent attempts cd ../worktree/test then git status; cd either silently doesn't persist or git status is blocked due to compound-form interactions.

Today (2026-04-25) I observed this with 5 of 5 subagents I dispatched — backend-engineer, frontend-engineer, infra-devops-specialist, and an audit + execute pair on the same dispatch. Even pwd && git status (no cd at all) was rejected for one of them.

Suggested Fix

Two complementary paths, ideally both:

  1. Restore CWD inheritance / persistence in subagents, matching main-thread Bash tool behavior. The main thread's Bash tool already persists CWD across calls; subagents should too.
  2. Add the cwd: parameter to Task (already requested at #12748). Even with #1 fixed, an explicit dispatch-time CWD removes ambiguity and helps with worktree workflows where the subagent's "starting directory" differs from the parent's.

Related

  • #33576 — original bug, locked
  • #35023 — TeamCreate variant, closed as duplicate of #33576
  • #12748 — feature request for cwd: parameter on Task tool (open)

extent analysis

TL;DR

The most likely fix involves restoring CWD inheritance in subagents or adding a cwd: parameter to the Task tool to explicitly set the working directory.

Guidance

  • Verify the issue by reproducing the steps provided, specifically launching a subagent and attempting to commit a change to a file in a non-default directory.
  • Investigate the feasibility of implementing the suggested fix of restoring CWD inheritance in subagents, potentially by reviewing the main-thread Bash tool behavior.
  • Consider the addition of the cwd: parameter to the Task tool as a complementary solution, which could provide an explicit way to set the working directory for subagents.
  • Review related issues (#33576, #35023, #12748) for additional context and potential insights into resolving the problem.

Notes

The provided information suggests that standard workarounds are blocked due to various restrictions, making it essential to address the root cause of the issue. The suggested fixes aim to restore CWD inheritance or provide an explicit way to set the working directory, which could alleviate the problem.

Recommendation

Apply the workaround by adding the cwd: parameter to the Task tool, as this provides an explicit and flexible solution to set the working directory for subagents, addressing the ambiguity in worktree workflows.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#tool integration#LLM response#prompt template

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Subagent Bash tool CWD does not inherit from Task launch context AND every workaround is blocked by security checks [1 comments, 2 participants]