EnterWorktree intermittently refuses a valid, already-registered worktree with "git identity could not be verified"

Environment

• OS: Windows 11 Enterprise, build 10.0.26200
• Git: git version 2.54.0.windows.1 (Git for Windows / MSYS)
• Claude Code desktop app
• Repo on local NTFS drive (C:\...), ~60 registered git worktrees at time of testing

What happened

Calling EnterWorktree(path=<target>) on an existing, previously-healthy,
already-registered worktree intermittently fails with:

Refusing to use <path> as an isolation worktree: git could not be run
to resolve it, so its git identity could not be verified. Isolation is
refused rather than assumed — recreate the worktree (or remove the
corrupt .git entry) and retry.

The same call, against the same unmodified target, later succeeds with
no changes made to the worktree in between. This is not a one-off: it
was reproduced independently across multiple separate sessions on the
same machine/repo over several days.

Is this the same bug as #91618?

Possibly related to #91618
(Windows case-sensitive drive-letter comparison in the isolation-worktree
safety check) — we can reproduce the same class of path representation
mismatch in our own environment:

$ git rev-parse --show-toplevel
C:/Users/.../worktrees/<name>          # uppercase drive, forward slashes

$ pwd
/c/Users/.../worktrees/<name>          # lowercase drive, POSIX-style (Git Bash)

However, our exact error text differs from #91618's (core.worktree
redirect vs. our git could not be run to resolve it), and our trigger
is a direct EnterWorktree(path=...) call rather than
agent(..., {isolation: 'worktree'}). Filing separately since the
symptom and entry point differ enough that conflating the two risks
either bug getting mis-triaged — happy to have a maintainer merge/link
these if they turn out to share a root cause.

Things we ruled out

Before filing, we spent significant effort investigating two other
theories, both dead ends — noting them so nobody has to re-derive this:

1. Retry timing. A workaround of "run one non-git action, then retry

EnterWorktree" appeared to work reliably (3/3) in an initial session,
but failed to reproduce in later sessions on the same repo (0/3, then
3/3 failures again). The failure is not simply a matter of waiting or
avoiding git-command adjacency.

1. Main-checkout ACL/permissions. We found orphaned/unresolvable SIDs

with DENY ACEs on the main checkout's .git ACL (consistent with a
domain/AAD migration), a plausible-looking candidate cause. A full ACL
repair (icacls ... /reset /T) was applied, and the identical failure
reproduced immediately afterward, unchanged, in two independent
sessions. Ruled out.

Reproduction notes

• The failure is intermittent, not deterministic — the same target

worktree can fail twice in a row and then succeed on a third attempt
with nothing else changed.

• The error text itself is not a reliable diagnostic signal: two

consecutive failures against the same target have blamed two different
paths (the target worktree vs. the main checkout) in different attempts.

• git status, git rev-parse --is-inside-work-tree, and other plain git

commands run cleanly and quickly against both the target worktree and
the main checkout throughout — from outside EnterWorktree, there is no
observable git-level problem.

Impact

When this fires, a session cannot switch into an existing worktree via
the sanctioned mechanism. The error message's own suggested remedy
("recreate the worktree or remove the corrupt .git entry") is risky
advice to follow in a repo with many concurrent worktrees, since blind
recreation can destroy another session's uncommitted work — we'd
recommend the error text itself not suggest this remedy for endings where
the cause is unconfirmed (see #91618's own troubleshooting-doc guidance
distinguishing confirmed-cause endings from generic ones).

Related

• #91618 (possibly same root cause, different symptom/entry point — see above)