Worktree resume fails with "could not verify worktree" due to git fetch timeout, not worktree corruption

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?

Resuming a Claude Code desktop session bound to a git worktree repeatedly fails with:

Error: could not verify worktree <path> for this resume, so the resume was aborted rather than continuing without isolation. This is usually transient — the worktree binding is kept; re-run the command to retry.

The error message claims the failure is transient, but in this case it persisted across ~2 hours, multiple "Try again" clicks, and a full OS reboot — with the target worktree confirmed healthy by every available check the whole time (no git locks, no index.lock, clean git status, normal disk/state size, no stray processes). Root cause confirmed via the app's own logs (see Error Messages/Logs below): the resume flow depends on a live git fetch of origin/master to refresh a diff base ref, and that fetch was timing out — most likely due to an intermittent corporate VPN/proxy (Zscaler) issue also observed independently during the same session.

What Should Happen?

When the remote (origin) is slow or unreachable, worktree-resume verification should degrade gracefully — e.g. continue with the on-disk ref, similar to the "refreshSourceRef" fallback behavior already visible in the app's own logs for a different ref-resolution step — rather than aborting the entire resume. At minimum, the error shown to the user should distinguish a network/fetch-timeout failure from filesystem/worktree corruption, since the current generic message sent significant debugging effort toward the wrong layer (git locks, state-directory bloat, worktree integrity — all checked and ruled out) before the real cause was found by manually inspecting local log files.

Error Messages/Logs

Error: could not verify worktree C:\Users\<user>\...\.claude\worktrees\<worktree-name> for this resume, so the resume was aborted rather than continuing without isolation. This is usually transient — the worktree binding is kept; re-run the command to retry.

From %LOCALAPPDATA%\Claude\logs\main1.log:
[info] [git-worker] [gitDiff] Base ref not found: master in ...worktrees\<name>, falling back to HEAD
  (repeated ~7x over several minutes)
[error] Git command failed: git symbolic-ref -q refs/remotes/origin/master { cwd: '...worktrees\<name>' }
[error] Git command failed: git fetch --no-write-fetch-head --no-prune --no-tags --no-prune-tags --refmap= origin +refs/heads/master:refs/remotes/origin/master { cwd: '...worktrees\<name>' }
[info] [refreshSourceRef] single-ref fetch of origin/master failed (continuing with on-disk ref): git fetch timed out { baseRepo: '...worktrees\<name>' }

A second log file (main2.log) shows the identical failure signature 12 days earlier, against a completely different worktree — confirming this is a recurring pattern, not specific to one worktree or repo state.

Steps to Reproduce

1. Open a long-running interactive Claude Code session bound to a git worktree, on a machine behind a corporate VPN/proxy (Zscaler in this case) with occasionally unreliable outbound connectivity to the git remote.
2. Work normally for an extended period (in this case, ~20+ minutes, including running a long external script).
3. At some point the session becomes unresponsive to new messages ("Claude couldn't process that message").
4. Click "Try again" — this surfaces: Error: could not verify worktree <path> for this resume, so the resume was aborted rather than continuing without isolation. This is usually transient — the worktree binding is kept; re-run the command to retry.
5. Repeated "Try again" clicks reproduce the same error consistently, including immediately after a full OS reboot (ruling out live process contention as sole cause).
6. Confirm via %LOCALAPPDATA%\Claude\logs\main*.log (Windows) that the failure coincides with:

[error] Git command failed: git fetch ... origin +refs/heads/master:refs/remotes/origin/master
[info] [refreshSourceRef] single-ref fetch of origin/master failed (continuing with on-disk ref): git fetch timed out

1. Confirm the target worktree itself has no git-level lock (.git/worktrees/<name>/locked absent, no index.lock), clean git status, and normal .claude/state/ size — ruling out repo-side causes.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.266 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Two unrelated issues were found and fixed while diagnosing this bug — noted here for context, not as the main report:

1. A hook script (check-mb-sentinel.ps1/.sh, part of a third-party Claude Code hook setup, not Claude Code itself) writes a new sentinel file per session/compaction event with no cleanup or TTL logic, causing unbounded accumulation in .claude/state/ over months of use in a long-lived worktree (138 stale files found in one case). This is unrelated to Anthropic's product but is mentioned in case anything in Claude Code's own worktree-verification step scans .claude/state/ contents as part of resume — if so, a bloated state directory could compound the network-timeout issue above by adding filesystem scan time on top of the fetch timeout.

1. A separate worktree had ~1.4MB of accidentally-committed scratch/debug output (a redirected git merge-tree dump) sitting in git history — removed as part of hygiene, but this did not affect the resume error, ruling it out as a contributing cause.

The consistent thread across this entire investigation: the desktop app's own local logs (%LOCALAPPDATA%\Claude\logs\main*.log on Windows) were the only source that revealed the actual root cause. Everything else (git state, worktree registration, disk/state size, process list) was normal throughout. Would strongly suggest either surfacing the underlying git-worker/fetch error to the user directly, or explicitly pointing to these log files in the "could not verify worktree" error message itself, since this saved significant time only once found by chance.