[BUG] Worktree session creation fails on Windows since 2.1.260: background full checkout forces checkout.workers=8

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Closest existing issues, all different root causes: #57048 (empty index, pathspec matches nothing, macOS, closed as duplicate), #47266 / #34645 (.git/config.lock contention between concurrent worktree add calls), #57767 (Windows locks on worktree removal), #39680 (EEXIST on an existing .claude/worktrees/).

Notably, the command quoted in #57048 contains no checkout.workers flag — that flag appears to be new in 2.1.260.

What's Wrong?

Since updating to Claude Code 2.1.260 (Claude Desktop 1.46388.1), every attempt to start a session with the worktree option fails on Windows.

The app creates the worktree, runs a 4-path selective checkout, then the background full checkout fails. The worktree is torn down immediately, so nothing appears in .claude/worktrees/, and the UI shows:

Impossible de changer de branche. / Unable to switch branch. Background full checkout failed: other

The failing command is:

git -c core.longpaths=true -c checkout.workers=8 checkout HEAD -- . :(exclude).claude

The root cause is checkout.workers=8. On this machine git's parallel checkout fails deterministically to create the very first directory it writes, whatever that directory is. Reduced to a minimal synthetic repository, the behaviour is:

| checkout.workers | Result |
|---|---|
| 1 | exit 0, all files written |
| 2 | exit 128 |
| 8 | exit 128 |

This is not repo-specific. I reproduced it on three unrelated repositories, including a throwaway repo of 120 files created seconds earlier in %TEMP% that has never been touched by Claude. The failure always lands on the first directory git tries to create (alpha, deploy, archive, Documentation — whichever comes first).

There is no user-side workaround: -c on the command line overrides any git config, and checkout.thresholdForParallelism is ignored when checkout.workers is set explicitly (verified up to 99999999).

The CLI path is unaffected: claude --worktree <name>, which performs a sequential checkout via git worktree add, works perfectly on the same machine at the same minute.

What Should Happen?

The worktree session should be created, as it was in 2.1.258 and every version before it.

Ideally the background full checkout should fall back to a single worker when the parallel checkout fails, rather than tearing down the worktree and aborting the session. That alone would restore the previous behaviour.

Error Messages/Logs

# From %LOCALAPPDATA%\claude\Logs\main.log

2026-09-04 08:58:43 [info] Creating worktree for session local_078bd705-...
2026-09-04 08:58:43 [info] [stageCheckout] Selective checkout done in 181ms (4 paths)
2026-09-04 08:58:44 [info] Created worktree "ticket-xxxx-896cb5" (prep=245ms fetch=0ms/throttled add=123ms stage1=181ms git_spawns=11)
2026-09-04 08:58:44 [info] Starting local session local_078bd705-... in ...\.claude\worktrees\ticket-xxxx-896cb5
2026-09-04 08:58:44 [error] Git command failed: git -c core.longpaths=true -c checkout.workers=8 checkout HEAD -- . :(exclude).claude
    { code: 128,
      stderr: "warning: unable to unlink 'Documentation': Directory not empty\n
               fatal: cannot create directory at 'Documentation': Directory not empty\n" }
2026-09-04 08:58:44 [warn] [CCD] first-turn init failed after worktree creation; removing orphaned worktree
2026-09-04 08:58:44 [info] Removed worktree "ticket-xxxx-896cb5"

Steps to Reproduce

Minimal, self-contained, no Claude involved — this reproduces the exact failure the app hits:

# 1. Build a throwaway repo: 120 files in 3 directories
cd "$(mktemp -d)"
git init -q .
git config user.email t@t && git config user.name t
for d in alpha bravo charlie; do
  mkdir -p "$d/sub"
  for i in $(seq 1 40); do echo x > "$d/sub/f$i.txt"; done
done
git add -A && git commit -qm minimal

# 2. Reproduce the app's two-stage checkout, at 1 then 2 then 8 workers
for w in 1 2 8; do
  rm -rf ../wt; git worktree prune; git branch -D wt 2>/dev/null
  git worktree add --no-checkout -b wt ../wt HEAD >/dev/null 2>&1
  git -C ../wt -c checkout.workers=$w checkout HEAD -- . 2>&1 | tail -1
  echo "workers=$w -> exit $?"
done

Observed:

workers=1 -> exit 0
fatal: cannot create directory at 'alpha': Directory not empty
workers=2 -> exit 128
fatal: cannot create directory at 'alpha': Directory not empty
workers=8 -> exit 128

To reproduce through the product: start a new session with the worktree option enabled on Windows. It fails every time.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version.

Evidence from main.log, counting successful worktree creations per day on this machine:

| Date | Created | Failed |
|---|---|---|
| 2026-08-28 | 4 | 0 |
| 2026-08-29 | 4 | 0 |
| 2026-08-30 | 8 | 0 |
| 2026-08-31 | 6 | 0 |
| 2026-09-01 | 12 | 0 |
| 2026-09-02 | 11 | 0 |
| 2026-09-03 | 18 | 0 |
| 2026-09-04 | 8 | 8 |

43 successful worktree creations over seven days, zero failures. Then 8 out of 8 failures today.

The string checkout.workers does not appear anywhere in the log between 2026-08-28 and 2026-09-04 07:16 — it first appears at 08:34:43, after the update. Timeline:

2026-09-03 12:05  claude-code 2.1.258 installed  -> 18 worktrees created that day, 0 failures
2026-09-04 07:05  [updater] Update downloaded { releaseName: 'Claude 1.46388.1' }
2026-09-04 07:16  claude-code 2.1.260 installed
2026-09-04 08:34  first failure

Nothing else changed on the machine: git was installed 2026-04-20, and a full reboot changed nothing.

Last Working Version

2.1.258

Claude Code Version

2.1.260 (Claude Code) — Claude Desktop 1.46388.1 (MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other — Claude Desktop app (the CLI in Windows Terminal is unaffected)

Additional Information

• Environment: Windows 11 Pro 10.0.26200.9168, git 2.54.0.windows.1 (installed 2026-04-20), Claude Desktop installed as an MSIX package. Windows Defender real-time protection is off; Acronis Cyber Protect filter drivers (snapman, tib_mounter) are loaded, which may be why parallel checkout races on this machine specifically. That said, those drivers were equally loaded yesterday, when all 18 worktree creations succeeded — the trigger is the new flag, not the environment.

• Why this is worth guarding against regardless of the local cause: git's parallel checkout is opt-in and defaults to a single worker, so forcing checkout.workers=8 exposes users to a code path that sees very little real-world use. Any filesystem filter driver (AV, backup, sync client) that makes directory creation non-atomic will trip it, and the user has no way to override a -c flag.

• Suggested fix: on failure of the parallel checkout, retry once with checkout.workers=1 before tearing down the worktree. Optionally expose the worker count as a setting.

• Worth noting that the teardown is silent about the real cause: the UI text mentions LFS, locked files and missing branches, none of which apply here, which sent me a long way down the wrong path before I found the actual git command in main.log.

git init r && cd r
mkdir -p a/b && echo x > a/b/f1.txt && echo x > a/b/f2.txt
git add -A && git commit -qm init
git worktree add --no-checkout wt --detach HEAD
git -C wt -c checkout.workers=2 checkout HEAD -- .