EnterWorktree / Agent isolation:worktree fails on Windows when session CWD contains a space

Summary

EnterWorktree (with name or path) and Agent({ isolation: "worktree" }) both fail in Claude Code sessions on Windows when the parent session's CWD contains a space, even though git worktree add invoked directly via the Bash tool from the same session works fine.

Environment

• OS: Windows 11
• Shell context: Claude Code's Bash tool (git-bash / MINGW64)
• Parent session CWD: c:\Users\Jason\JP Laptop Dev\HeyRoot (the space in "JP Laptop Dev" is load-bearing for the repro)
• Discovered: 2026-05-22

Repro

1. Open a Claude Code session whose working directory contains a space.
2. Try to enter or create a worktree via the tool:

``
EnterWorktree({ name: "test-worktree" })
``

or

``
Agent({
description: "test",
prompt: "...",
isolation: "worktree"
})
``

1. Observe failure (paraphrased; exact strings below):

``
Failed to create worktree: Command 'git' not found or is in an unsafe location (current directory)
``

And when EnterWorktree is invoked with path for an existing worktree:

``
git -C c:\Users\Jason\JP Laptop Dev\HeyRoot worktree list failed:
Command 'git' not found or is in an unsafe location (current directory)
``

Expected

The worktree is created (or entered) and the session/agent proceeds with isolated work.

Actual

Both tools fail with the "unsafe location" error. This blocks the canonical multi-agent parallel-isolation pattern on Windows when the working directory contains a space — which is a common case (Documents, Program Files derivatives, user-chosen dev directories like "JP Laptop Dev").

What works

git worktree add invoked directly via the Bash tool from the SAME session works fine:

git worktree add -b feat/test-branch C:/tmp/no-space-path origin/main

So git itself is OK in the session; only the harness's invocation path fails.

Workaround in use

1. Create the worktree manually via Bash at a no-space path: git worktree add C:/tmp/<slug> <branch> <base-ref>
2. Spawn Agent WITHOUT isolation: "worktree"; pass the worktree path absolutely in the agent's prompt; the agent cd <path> as its first Bash command (Bash CWD persists across calls within a single agent session).
3. For session-level work: do NOT call EnterWorktree; operate on the worktree's files via absolute paths from Bash + Read/Edit/Write tools (those accept absolute paths fine).

This works but loses the isolation parameter's automatic-cleanup feature, and forces every subagent prompt to remember the absolute-path discipline.

Hypothesis

The harness invokes git -C <cwd> in a context (Node ESM resolver / harness PATH propagation / spawn options) that doesn't honor the user's .gitconfig safe.directory entries. Bash inherits the full shell environment + safe.directory config, which is why direct Bash invocation works.

May also be a Windows safe.directory (CVE-2022-24765 protection) check tripping on the spaced path representation. Worth checking whether the harness normalizes the path before passing it to git.

Impact

For the affected user, this came up during a multi-PR substrate-work session where parallel Agent({ isolation: "worktree" }) would have been the canonical pattern per the team's CLAUDE.md guidance. The manual workaround cost ~30 minutes of detours across three sequential deploys.

Suggested fix directions

• Have the worktree harness pre-add the spaced CWD path to safe.directory before invoking git -C, OR
• Use the resolved-absolute-no-space path for the -C flag, OR
• Pass the session's git config (including any user-level safe.directory entries) into the spawn environment.

Happy to test a fix if one lands.