[BUG] Claude Desktop 1.15962.1 (macOS) — 69s main-thread freeze on every launch after [buddy] bridge started, persists through full reset + reinstall
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?
Claude Desktop freezes (spinning beach ball) for ~60–70 seconds on every launch. The main process is blocked, UI unresponsive, window occasionally disappears and reappears.
macOS (Apple Silicon / arm64)
Claude Desktop 1.15962.1
Node 24.16.0 (bundled)
[info] [buddy] starting bridge
[info] [buddy] bridge started
[warn] [event-loop-stall] main process blocked for 69726ms [likely sleep/wake] (total 0, cumulative 0ms)
[warn] [sessions-bridge] Failed to reconnect session cse_...: This operation was aborted
The block is consistently ~69,000–70,000ms and fires immediately after [buddy] bridge started.
sample of the main process during the freeze shows the main thread is NOT idle/suspended — it is actively pegged in V8 with heavy GC churn (so the [likely sleep/wake] label is misleading):
CrBrowserMain → ElectronMain → __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
→ v8::internal::compiler::CompilationDependencies...
→ cppgc::internal::MakeGarbageCollectedTraitInternal::Allocate
→ v8::Exception::TypeError
What I tried that did NOT fix it:
Cleared local-agent-mode-sessions (relaunched with existingSessions=0) — no change
Removed bridge-state.json (stale cse_/env_ reconnect pointer) — no change
Removed all custom/extra MCP servers — no change
Full Reset App Data — no change (identical 69s stall on fresh state)
Clean reinstall of latest version from fresh download — no change
Confirmed unrelated to shell env (separate Oh My Zsh prompt hang was fixed independently)
Expected: App launches without a 60–70s main-thread block. The Cowork/buddy bridge reconnect should not block the UI thread synchronously, and should fail fast when the remote session/environment is unreachable.
What Should Happen?
App launches and reaches an interactive state within a few seconds, without the main process blocking. Specifically, the Cowork/buddy bridge reconnect should run asynchronously (off the main thread) and fail fast when the remote session/environment is unreachable, instead of blocking the UI thread synchronously for ~69 seconds on every launch.
Error Messages/Logs
Steps to Reproduce
Launch Claude Desktop on macOS (version 1.15962.1, Apple Silicon).
Observe the spinning beach ball / unresponsive window immediately after startup.
Check ~/Library/Logs/Claude/main.log — note [buddy] bridge started followed by [event-loop-stall] main process blocked for ~69700ms.
The freeze lasts ~60–70 seconds, then the app becomes responsive.
Repeats on every launch, including after Reset App Data and after a clean reinstall of the latest version.
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
1.15962.1
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
iTerm2
Additional Information
_No response_
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
👎
Possibly related to #68316 (macOS desktop wedging on a backgrounded/reaped helper process). On the launch where you get the 69s freeze, does
~/Library/Logs/Claude/main.logshow this line around the stall?If so, this may be a launch-time variant of the same App Nap helper-reaping issue, and disabling App Nap is worth a try:
(then fully quit + relaunch). If your freeze happens with no such line — i.e. it's purely a main-thread stall after
[buddy] bridge startedwith networking intact — then it's a distinct bug and this won't help.---
Update: following up — on my machine the
Network Service process gone (exitCode=15)kills were caused by Tailscale MagicDNS (100.100.100.100) being the primary resolver and intermittently wedging;tailscale set --accept-dns=falsestopped them completely. If your 69s launch freeze coincides with that log line, checkscutil --dnsfor a VPN/MagicDNS primary resolver. If your freeze has networking intact (no such line), it's a separate bug. Details in #68316.---
Update: following up — on my machine the
Network Service process gone (exitCode=15)kills were caused by Tailscale MagicDNS (100.100.100.100) being the primary resolver and intermittently wedging;tailscale set --accept-dns=falsestopped them completely. If your 69s launch freeze coincides with that log line, checkscutil --dnsfor a VPN/MagicDNS primary resolver. If your freeze has networking intact (no such line), it's a separate bug. Details in #68316.---
Update — root cause confirmed, and it's broader than the DNS angle in my comment above. I isolated it with a controlled test: the trigger is network-change events, typically from a VPN/overlay network (Tailscale in my case) — not DNS specifically, and not App Nap. Toggling the overlay network off → app stable for 46 min with zero recycles; toggling it back on → blank within seconds. Each network change recycles Chromium's NetworkService and the Electron main process fails to rebind to the respawned one. If you're hitting this, check whether you run a VPN/overlay (Tailscale, Cloudflare WARP, corporate VPN) or switch networks/sleep-wake often, and test by disabling it. Full analysis + a 1-minute repro in #68316.
That's what I get:
2026-06-30 07:31:32 [info] [buddy] starting bridge2026-06-30 07:31:32 [info] [buddy] bridge started
2026-06-30 07:32:38 [warn] [event-loop-stall] main process blocked for 65688ms [likely sleep/wake] (total 0, cumulative 0ms, rss 5
2026-06-30 07:33:52 [warn] [event-loop-stall] main process blocked for 529ms (total 1, cumulative 529ms, rss 410MB)
Seeing what looks like a related but distinct variant on 1.18286.0 (macOS 26.5.1, Apple Silicon).
Difference from the OP: in my case the main-thread block does not release after ~69s — it hangs indefinitely at ~100% CPU until force-quit, and no logs are written at all (main.log / claude.ai-web.log frozen at the previous session's timestamp, so it stalls before the logger initializes).
sample of the hung main process shows all samples in a libuv check-loop chain rather than the [buddy]/GC path:
uv_run → uv__run_check → node::Environment::CheckImmediate(uv_check_s*)
Key difference from #69366 (closed dup): launching with open -a Claude --args --disable-gpu reliably fixes it for me — the app starts normally and CPU drops to idle. So on my machine this points at the GPU/graphics init path, not the Cowork bridge.
Full sample attached. Happy to file separately if you'd prefer to keep this scoped to the ~69s buddy-bridge case.
Possibly related, but likely distinct: permanent main-thread hang at cold start on Apple Silicon, worked around by
--disable-gpu.Environment: macOS 26.5.1, MacBook Air (Apple Silicon), Claude Desktop 1.19367.0. Reproduces on every normal launch since ~1.17377.2 (last known-good: 1.15962.2); survived 3 auto-updates.
Symptoms differ from this issue in two ways: the hang never releases (killed after 2.5+ min at sustained 100% CPU on the main thread), and the stack is not in the [buddy] bridge/GC — it's a busy JS loop very early in bootstrap:
100% of ~6800 samples sit in this one chain. No crash/hang reports are ever written to DiagnosticReports — it hangs before the watchdog/logger initializes.
Notably the main thread is executing JS, not blocked on GPU IPC — the GPU helper process is alive (running with
--use-gl=disabled).open -a Claude --args --disable-gpureliably fixes startup, so the GPU-detection outcome appears to steer an early-bootstrap JS path into an infinite loop. Clicking the Dock icon while a--disable-gpuinstance is running also hangs it on the activate/focus path.Full
sampleoutput available on request. Happy to test builds or gather more data.Update: fixed in 1.20186.0.
Confirmed on the same machine (macOS 26.5.1, MacBook Air, Apple Silicon) that was hitting the permanent main-thread hang described above (uv_run → CheckImmediate JS loop,
--disable-gpuworkaround) on every version from ~1.17377.2 through 1.19367.0.After updating to 1.20186.0, the app launches normally without
--disable-gpu— verified on the actual production instance (not just an isolated test copy): main process at ~3.5% CPU, state S, window opens normally, no hang. Workaround is no longer needed on this machine.Thanks for whatever changed between 1.19367.0 and 1.20186.0 — this one was rough since it hung before any logs were written, making it hard to report.