Claude Desktop: GitHubPrManager polling stalls main process with several worktrees on Windows (1.9255.2.0)

Summary

On Windows, Claude Desktop's GitHubPrManager polls gh pr view and gh pr checks per tracked worktree branch. With several active worktrees the polls contend for the same gh/network resources, individual gh calls balloon from a few seconds to 30-40+ seconds, and the main process accumulates event-loop stalls. The UI becomes laggy across all open chats and stays that way until app restart.

Versions before this (1.9255.0.0 and 1.9255.2.0) both shipped attempted fixes for GitHubPrManager — the user-visible symptom is unchanged on 1.9255.2.0.

Environment

• Claude Desktop 1.9255.2.0 (MSIX, Anthropic.Claude from winget — latest available, winget search confirms no newer build)
• Windows 11 Pro for Workstations 10.0.26200
• gh 2.x at C:\Program Files\GitHub CLI\gh.exe, authenticated, rate-limit healthy (4990/5000 core remaining)
• Defender real-time protection on (tested both with and without gh.exe exclusion — see below)
• 6 active worktrees across 2 repos (5 in aegis-agent, 1 in aegis-expenses), each leased by an open chat session, each with an associated open PR

Symptom signature in %APPDATA%\Claude\logs\main.log

[error] [GitHubPrManager] Failed to get PR state for branch: gh pr view timed out
  at Timeout.<anonymous> (C:\Program Files\WindowsApps\Claude_1.9255.2.0_x64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:204:128870)
[warn] [event-loop-stall] main process blocked for 3148ms (total 4, cumulative 6752ms, rss 347MB)
[info] LocalSessions.getPrChecks: cwd=...\worktrees\<branch>, prNumber=<N>, repo=<none>

Stall counts accumulate steadily — observed 31 stalls / 24.8s cumulative blocked over ~15 minutes of normal use, RSS climbing into 600-700MB range.

Reproduction

1. Open 6 Claude Desktop chats, each with a worktree (.claude/worktrees/<name>) on a branch that has a corresponding open GitHub PR.
2. Let the app run for 10-15 minutes.
3. Observe: foreground chat input latency, button presses delayed, scrolling stutters. main.log shows getPrChecks firing per worktree on a tight cadence and event-loop-stall warnings climbing.

Concrete timings

Measured from PowerShell in one of the worktree directories (the same cwd Claude Desktop uses):

| Test | Result |
|---|---|
| gh pr view --json state,statusCheckRollup baseline | 9.14s |
| gh pr checks baseline | 5.27s |
| gh pr view × 3 with Claude Desktop polling active | 12.75s, 9.14s, 31.03s |
| gh pr checks × 3 with Claude Desktop polling active | 34.6s, 20.48s, 41.98s |
| Same after adding Defender exclusion for gh.exe | no improvement — wild variance persists |

The wild per-call variance is the smoking gun: when polling is quiescent, gh runs ~1-2s in this repo; when 6 worktrees are being polled concurrently, individual calls balloon to 30-40s. This is concurrent-gh contention, not Defender overhead, not network bandwidth (rate-limit shows ~200 of 5000 core used).

What's been ruled out

• Stale git-worktrees.json entries (all 6 paths exist on disk)
• GitHub rate-limiting (well under quota)
• Defender real-time scanning of gh.exe (exclusion added, no change)
• gh auth / config (auth healthy, repo correctly inferred from cwd)

Concrete ask

Any of these would unblock heavy-worktree users today:

1. Config kill-switch for the polling — env var (CLAUDE_DISABLE_PR_TRACKING=1) or settings.json flag. Cheapest fix; users with this workload self-opt-out.
2. Single-flight + longer interval — don't queue a new poll for a branch while one is in flight, raise the base interval (60s → 300s+) when there are >N tracked branches.
3. Move polling off the main process — utility worker so subprocess waits don't translate into event-loop stalls.

Happy to capture more logs or test a patched build.