[BUG] Claude Desktop 1.15962.1 (macOS) — 69s main-thread freeze on every launch after [buddy] bridge started, persists through full reset + reinstall

Open 💬 7 comments Opened Jun 28, 2026 by ataffard

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_

View original on GitHub ↗

This issue has 7 comments on GitHub. Read the full discussion on GitHub ↗