[BUG] Windows: worktree git-repo detection fails at call time — EnterWorktree({name}) and Agent isolation:"worktree" both falsely report "not in a git repository"

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, both worktree entry points — EnterWorktree({ name }) and Agent({ isolation: "worktree" }) — fail with "not in a git repository…" even though the working directory is a valid, pre-existing git repository. It's a call-time detection failure, not a missing repo: Claude Code's own startup banner reports "Is a git repository: true," and git rev-parse, git worktree list, and git remote -v all succeed from the same directory microseconds before the failing call. This is the same root cause as #40164 (auto-closed as stale, not fixed — still reproduced there on 2.1.128) and is distinct from #68214 (the macOS in-session-git init caching variant, where pre-existing repos work fine).

What Should Happen?

The worktree is created. For the name form, a linked worktree on branch worktree-<name> is created and the session cwd repoints into it; for Agent isolation:"worktree", the subagent runs in its own worktree. No "not in a git repository" error in a valid repo, and no need to configure WorktreeCreate hooks.

Error Messages/Logs

Cannot create a worktree: not in a git repository and no WorktreeCreate hooks are configured. Configure WorktreeCreate/WorktreeRemove hooks in settings.json to use worktree isolation with other VCS systems. (Agent-isolation variant, per #40164: Cannot create agent worktree: … followed by Not a git repo — spawning without worktree isolation.) A #40164 commenter observed the pre-check fails in ~3 ms and session metadata shows "HEAD" instead of the branch name.

Steps to Reproduce

1. On Windows, create a minimal git repo and enter it:

mkdir C:\repro
cd C:\repro
git init
git commit --allow-empty -m "init"

1. Open Claude Code with its working directory set to C:\repro (the startup banner should show "Is a git repository: true").
2. From the Bash tool (Git Bash), confirm it's a valid repo — all succeed:

git rev-parse --show-toplevel · git worktree list · git remote -v

1. Call EnterWorktree({ name: "test" }) (or spawn Agent({ isolation: "worktree", subagent_type: "general-purpose", prompt:

"noop" })).

1. Observe the error above instead of a created worktree.

• Workaround that succeeds (for contrast): git worktree add .claude/worktrees/test -b worktree-test HEAD then EnterWorktree({

path: ".claude/worktrees/test" }) — the path form works; only the name form fails.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.183 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• Recurrence of #40164 (auto-closed by github-actions[bot] as stale, not maintainer-declined — its closing message says

"Please open a new issue if this is still relevant"; labels: bug, has repro, platform:windows, area:agents, stale). No
maintainer ever triaged it.

• Distinct from #68214 (Open) — the macOS in-session-git init caching variant; that reporter confirms pre-existing repos work,

so this is a separate path-resolution cause.

• Suspected root cause: POSIX (/c/...) vs Windows (C:\...) path normalization in the call-time .git detection — the startup

detection succeeds but the call-time re-check fails.

• Affects both EnterWorktree({ name }) and Agent({ isolation: "worktree" }).
• Community workarounds (#40164): configure WorktreeCreate/WorktreeRemove hooks (bypasses the detection, tested on Win 11);

GIT_DIR env var; run from repo root; Git Bash path forms.

• External ref: gsd-build/get-shit-done#2094.