›_ Claude Code Issues
Claude Code Issues / #76725

[BUG] Bug: Claude Desktop main webview repeatedly becomes unresponsive during startup on Windows 10 (MSIX), causing multi-minute hang / kill-and-reload loop

Open 💬 0 comments Opened Jul 11, 2026 by lke260520-boop

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?

Environment

OS: Windows 10
Install method: MSIX (Microsoft Store), PackageFamilyName: Claude_xxxxxxxxxx
Affected versions: 1.17377.2.0 → 1.19367.0.0 (issue persists across auto-update and clean reinstall)
Node version (from logs): 24.17.0

Summary
On every cold start, the main webview becomes unresponsive roughly 50-90 seconds after launch, gets killed and reloaded by the app's own watchdog, then becomes unresponsive again shortly after — repeating 2-3 times before the app finally stabilizes, typically taking ~5-6 minutes total before it becomes usable. claude.ai (web) loads and works normally throughout, on the same machine, under the same network conditions, ruling out account/backend/network availability as the cause.

Key log evidence

[WarmLifecycle:cowork] Initialized (arm=always) — Cowork's warm-lifecycle policy is armed as "always," unlike WarmLifecycle:session and WarmLifecycle:preview, which are armed when-hidden. This appears to apply even for accounts that don't actively use Cowork.
Repeated cycle observed 2-3 times per cold start, ~50-90s apart, each with a distinct Sentry eventId:

[info] Main webview is unresponsive, will kill and reload
[error] Sentry caught: { value: 'Main webview became unresponsive' }

The full account bootstrap sequence takes several minutes to complete:

18:47:49 [info] [account] Account details not yet available, waiting for IPC...
18:47:54 [info] [account] IPC did not provide accountUuid, falling back to bootstrap API
...
18:53:34 [info] claude.ai account active and logged in
18:53:34 [info] [WarmLifecycle:cowork] Destroyed

WarmLifecycle:cowork is only Destroyed once the account becomes active — during the multi-minute bootstrap window it remains armed, competing with other startup tasks (worktree sweep, MCP/bridge init) for the main thread.

[WorktreePool] sweep: skipping (sessions not loaded) — worktree sweep is blocked waiting on session data, consistent with multiple startup subsystems stalling on the same slow bootstrap path.
Non-fatal but suspicious: [watch-record] failed to subscribe to swift events: (intermediate value).default.on is not a function
%APPDATA%\Claude\vm_bundles repeatedly grows to ~9.5-9.8GB even without any active Cowork usage, and regrows within a day of being deleted.

Steps taken to isolate (all failed to resolve on their own)

Deleted vm_bundles, Cache, Code Cache — temporarily improves startup, but vm_bundles regrows to ~9.5GB within a day and the hang returns.
Cleared git-worktrees.json — no effect (file was near-empty, 41 bytes, not a factor).
Full offline test (network disconnected) — hang still occurs; rules out VPN/firewall/bridge-reconnect as the cause.
Full uninstall (Remove-AppxPackage) + manual deletion of %APPDATA%\Claude, %LOCALAPPDATA%\Claude, %LOCALAPPDATA%\Packages\Claude_xxxxxxxxxxxxx + clean reinstall — resolved the issue for about a day, then recurred with vm_bundles back at 9.58GB and the same webview-unresponsive loop.
Web version (claude.ai) starts and works normally throughout on the same machine — confirms the issue is local to the desktop client, not account/network/backend availability.
Measured network quality to api.anthropic.com: avg latency 464ms, 5% packet loss (20 packets sent, 1 lost, min 431ms / max 591ms). This is elevated but not a severe network fault — moderate latency + minor packet loss is common in many regions. Critically, claude.ai (web) tolerates this same network condition without issue.

Root cause theory
The main webview hang is not primarily caused by Cowork VM work itself, but by the account/IPC bootstrap sequence taking several minutes to complete under moderate network latency (~450ms) with minor packet loss (~5%). During this extended bootstrap window, WarmLifecycle:cowork remains armed (arm=always) and only gets Destroyed once the account becomes active, suggesting it competes with bootstrap-dependent tasks for the main thread. The web client tolerates the identical network conditions gracefully (async, non-blocking requests), while the desktop client's account bootstrap appears to block or starve the main/render thread, causing the webview to repeatedly hang and get killed/reloaded.

Request

Make the account/IPC bootstrap sequence resilient to moderate latency and minor packet loss — non-blocking, off the main thread, with reasonable timeout/backoff — matching the web client's tolerance of the same network conditions.
Consider changing WarmLifecycle:cowork's default arm policy from always to something conditional on actual Cowork usage (consistent with WarmLifecycle:session / WarmLifecycle:preview, both armed when-hidden), so it isn't competing for resources during the bootstrap window for users who don't use Cowork.
Please investigate why vm_bundles grows to ~9.5GB+ without any active Cowork usage.

What Should Happen?

Make the account/IPC bootstrap sequence resilient to moderate latency and minor packet loss — non-blocking, off the main thread, with reasonable timeout/backoff — matching the web client's tolerance of the same network conditions.
Consider changing WarmLifecycle:cowork's default arm policy from always to something conditional on actual Cowork usage (consistent with WarmLifecycle:session / WarmLifecycle:preview, both armed when-hidden), so it isn't competing for resources during the bootstrap window for users who don't use Cowork.
Please investigate why vm_bundles grows to ~9.5GB+ without any active Cowork usage.

Error Messages/Logs

Environment


OS: Windows 10
Install method: MSIX (Microsoft Store), PackageFamilyName: Claude_xxxxxxxxxx
Affected versions: 1.17377.2.0 → 1.19367.0.0 (issue persists across auto-update and clean reinstall)
Node version (from logs): 24.17.0


Summary
On every cold start, the main webview becomes unresponsive roughly 50-90 seconds after launch, gets killed and reloaded by the app's own watchdog, then becomes unresponsive again shortly after — repeating 2-3 times before the app finally stabilizes, typically taking ~5-6 minutes total before it becomes usable. claude.ai (web) loads and works normally throughout, on the same machine, under the same network conditions, ruling out account/backend/network availability as the cause.

Key log evidence


[WarmLifecycle:cowork] Initialized (arm=always) — Cowork's warm-lifecycle policy is armed as "always," unlike WarmLifecycle:session and WarmLifecycle:preview, which are armed when-hidden. This appears to apply even for accounts that don't actively use Cowork.
Repeated cycle observed 2-3 times per cold start, ~50-90s apart, each with a distinct Sentry eventId:


   [info] Main webview is unresponsive, will kill and reload
   [error] Sentry caught: { value: 'Main webview became unresponsive' }


The full account bootstrap sequence takes several minutes to complete:

   18:47:49 [info] [account] Account details not yet available, waiting for IPC...
   18:47:54 [info] [account] IPC did not provide accountUuid, falling back to bootstrap API
   ...
   18:53:34 [info] claude.ai account active and logged in
   18:53:34 [info] [WarmLifecycle:cowork] Destroyed

WarmLifecycle:cowork is only Destroyed once the account becomes active — during the multi-minute bootstrap window it remains armed, competing with other startup tasks (worktree sweep, MCP/bridge init) for the main thread.

[WorktreePool] sweep: skipping (sessions not loaded) — worktree sweep is blocked waiting on session data, consistent with multiple startup subsystems stalling on the same slow bootstrap path.
Non-fatal but suspicious: [watch-record] failed to subscribe to swift events: (intermediate value).default.on is not a function
%APPDATA%\Claude\vm_bundles repeatedly grows to ~9.5-9.8GB even without any active Cowork usage, and regrows within a day of being deleted.


Steps taken to isolate (all failed to resolve on their own)

Deleted vm_bundles, Cache, Code Cache — temporarily improves startup, but vm_bundles regrows to ~9.5GB within a day and the hang returns.
Cleared git-worktrees.json — no effect (file was near-empty, 41 bytes, not a factor).
Full offline test (network disconnected) — hang still occurs; rules out VPN/firewall/bridge-reconnect as the cause.
Full uninstall (Remove-AppxPackage) + manual deletion of %APPDATA%\Claude, %LOCALAPPDATA%\Claude, %LOCALAPPDATA%\Packages\Claude_xxxxxxxxxxxxx + clean reinstall — resolved the issue for about a day, then recurred with vm_bundles back at 9.58GB and the same webview-unresponsive loop.
Web version (claude.ai) starts and works normally throughout on the same machine — confirms the issue is local to the desktop client, not account/network/backend availability.
Measured network quality to api.anthropic.com: avg latency 464ms, 5% packet loss (20 packets sent, 1 lost, min 431ms / max 591ms). This is elevated but not a severe network fault — moderate latency + minor packet loss is common in many regions. Critically, claude.ai (web) tolerates this same network condition without issue.


Root cause theory
The main webview hang is not primarily caused by Cowork VM work itself, but by the account/IPC bootstrap sequence taking several minutes to complete under moderate network latency (~450ms) with minor packet loss (~5%). During this extended bootstrap window, WarmLifecycle:cowork remains armed (arm=always) and only gets Destroyed once the account becomes active, suggesting it competes with bootstrap-dependent tasks for the main thread. The web client tolerates the identical network conditions gracefully (async, non-blocking requests), while the desktop client's account bootstrap appears to block or starve the main/render thread, causing the webview to repeatedly hang and get killed/reloaded.

Request


Make the account/IPC bootstrap sequence resilient to moderate latency and minor packet loss — non-blocking, off the main thread, with reasonable timeout/backoff — matching the web client's tolerance of the same network conditions.
Consider changing WarmLifecycle:cowork's default arm policy from always to something conditional on actual Cowork usage (consistent with WarmLifecycle:session / WarmLifecycle:preview, both armed when-hidden), so it isn't competing for resources during the bootstrap window for users who don't use Cowork.
Please investigate why vm_bundles grows to ~9.5GB+ without any active Cowork usage.

Steps to Reproduce

Environment

OS: Windows 10
Install method: MSIX (Microsoft Store), PackageFamilyName: Claude_xxxxxxxxxx
Affected versions: 1.17377.2.0 → 1.19367.0.0 (issue persists across auto-update and clean reinstall)
Node version (from logs): 24.17.0

Summary
On every cold start, the main webview becomes unresponsive roughly 50-90 seconds after launch, gets killed and reloaded by the app's own watchdog, then becomes unresponsive again shortly after — repeating 2-3 times before the app finally stabilizes, typically taking ~5-6 minutes total before it becomes usable. claude.ai (web) loads and works normally throughout, on the same machine, under the same network conditions, ruling out account/backend/network availability as the cause.

Key log evidence

[WarmLifecycle:cowork] Initialized (arm=always) — Cowork's warm-lifecycle policy is armed as "always," unlike WarmLifecycle:session and WarmLifecycle:preview, which are armed when-hidden. This appears to apply even for accounts that don't actively use Cowork.
Repeated cycle observed 2-3 times per cold start, ~50-90s apart, each with a distinct Sentry eventId:

[info] Main webview is unresponsive, will kill and reload
[error] Sentry caught: { value: 'Main webview became unresponsive' }

The full account bootstrap sequence takes several minutes to complete:

18:47:49 [info] [account] Account details not yet available, waiting for IPC...
18:47:54 [info] [account] IPC did not provide accountUuid, falling back to bootstrap API
...
18:53:34 [info] claude.ai account active and logged in
18:53:34 [info] [WarmLifecycle:cowork] Destroyed

WarmLifecycle:cowork is only Destroyed once the account becomes active — during the multi-minute bootstrap window it remains armed, competing with other startup tasks (worktree sweep, MCP/bridge init) for the main thread.

[WorktreePool] sweep: skipping (sessions not loaded) — worktree sweep is blocked waiting on session data, consistent with multiple startup subsystems stalling on the same slow bootstrap path.
Non-fatal but suspicious: [watch-record] failed to subscribe to swift events: (intermediate value).default.on is not a function
%APPDATA%\Claude\vm_bundles repeatedly grows to ~9.5-9.8GB even without any active Cowork usage, and regrows within a day of being deleted.

Steps taken to isolate (all failed to resolve on their own)

Deleted vm_bundles, Cache, Code Cache — temporarily improves startup, but vm_bundles regrows to ~9.5GB within a day and the hang returns.
Cleared git-worktrees.json — no effect (file was near-empty, 41 bytes, not a factor).
Full offline test (network disconnected) — hang still occurs; rules out VPN/firewall/bridge-reconnect as the cause.
Full uninstall (Remove-AppxPackage) + manual deletion of %APPDATA%\Claude, %LOCALAPPDATA%\Claude, %LOCALAPPDATA%\Packages\Claude_xxxxxxxxxxxxx + clean reinstall — resolved the issue for about a day, then recurred with vm_bundles back at 9.58GB and the same webview-unresponsive loop.
Web version (claude.ai) starts and works normally throughout on the same machine — confirms the issue is local to the desktop client, not account/network/backend availability.
Measured network quality to api.anthropic.com: avg latency 464ms, 5% packet loss (20 packets sent, 1 lost, min 431ms / max 591ms). This is elevated but not a severe network fault — moderate latency + minor packet loss is common in many regions. Critically, claude.ai (web) tolerates this same network condition without issue.

Root cause theory
The main webview hang is not primarily caused by Cowork VM work itself, but by the account/IPC bootstrap sequence taking several minutes to complete under moderate network latency (~450ms) with minor packet loss (~5%). During this extended bootstrap window, WarmLifecycle:cowork remains armed (arm=always) and only gets Destroyed once the account becomes active, suggesting it competes with bootstrap-dependent tasks for the main thread. The web client tolerates the identical network conditions gracefully (async, non-blocking requests), while the desktop client's account bootstrap appears to block or starve the main/render thread, causing the webview to repeatedly hang and get killed/reloaded.

Request

Make the account/IPC bootstrap sequence resilient to moderate latency and minor packet loss — non-blocking, off the main thread, with reasonable timeout/backoff — matching the web client's tolerance of the same network conditions.
Consider changing WarmLifecycle:cowork's default arm policy from always to something conditional on actual Cowork usage (consistent with WarmLifecycle:session / WarmLifecycle:preview, both armed when-hidden), so it isn't competing for resources during the bootstrap window for users who don't use Cowork.
Please investigate why vm_bundles grows to ~9.5GB+ without any active Cowork usage.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

1.19367.0.0

Claude Code Version

1.19367.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗