claude-code - 💡(How to fix) Fix [BUG] Claude desktop 1.5354.0 hangs after launch — no window, no renderer process spawned (macOS 26.4.1) [1 participants]

Summary

After Squirrel auto-updated Claude desktop to 1.5354.0 at 03:39 local on 2026-04-29, the app launches but never creates its main window. The process registers in AppKit (visible in dock, app menu populated with default macOS items only), GPU and Network helpers spawn correctly, but no --type=renderer subprocess is ever created, no window appears, and the app's custom menu items (Sign In, New Conversation, Settings, etc.) are never registered. There is no crash, no error in stderr, no Crashpad dump.

The bug reproduces with a completely empty user-data-dir (--user-data-dir=/tmp/claude-fresh-$$), which rules out any profile/config corruption and points squarely at the 1.5354.0 binary.

Environment

• App: Claude desktop 1.5354.0 (com.anthropic.claudefordesktop)
  • Binary timestamp: 2026-04-29 03:39 (Squirrel auto-update)
  • Universal binary (x86_64 + arm64)
  • Codesign: valid, notarized, Developer ID Application: Anthropic PBC (Q6L2SF6YDW), timestamped 2026-04-29 03:36:54
  • Runtime Version: 26.2.0
  • Gatekeeper: accepted, source=Notarized Developer ID
• OS: macOS 26.4.1 (build 25E253) — Tahoe
• Hardware: Mac Studio (Mac16,9), Apple M4 Max, 128 GB RAM, 40-core GPU, Metal 4
• Display: LG ULTRAFINE 5120×2160 @ 120 Hz (Ultra-wide 5K), single display, main
• Claude Code CLI: functional (only the desktop app is broken)

Steps to reproduce

1. Have Claude desktop 1.5354.0 installed (this version was pushed automatically to me via Squirrel; I don't have an earlier .dmg to roll back).
2. Launch the app: open -a Claude, double-click in Finder, or launch directly:

   /Applications/Claude.app/Contents/MacOS/Claude

3. Wait 5–10 seconds.
4. Observe: no window appears. The dock icon shows the app as running.

Expected behavior

A BrowserWindow opens, custom menu items are registered, the app connects to the backend.

Actual behavior

• No window. Ever.
• osascript reports windows=0, visible=true, frontmost=true after activate.
• Process tree contains only main + --type=gpu-process + --type=utility --utility-sub-type=network.mojom.NetworkService. No --type=renderer is ever spawned.
• Cmd+N does nothing (no New Window / New Conversation handler is registered).
• App stays alive forever. No crash, no exit, no Crashpad dump.

Menu bar contents (key indicator that JS bootstrap aborted early)

The menu bar contains only the default Cocoa items that AppKit creates automatically. None of the app's custom menu items are registered:

• File menu items: Close Window, Cerrar todo (← only the AppKit defaults; no New Window, no New Conversation)
• Claude menu items: About Claude, Services, Hide Claude, Hide Others, Show All, Quit Claude (← only the AppKit defaults; no Settings, no Sign In/Sign Out)

This strongly suggests the main process JS aborts before registering Menu.setApplicationMenu(...) and before calling new BrowserWindow(...).

Main thread sample (5 s)

The main thread sits idle in the normal Cocoa run loop:

4235 Thread_*   DispatchQueue_1: com.apple.main-thread  (serial)
+ 4235 start  (in dyld) + 6992
+   4235 ElectronMain  (in Electron Framework) + 120
+     4235 v8::Context::FromSnapshot(...)
+       ...
+         4235 -[NSApplication run]
+           4235 -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:]
+             ...
+               4235 _CFRunLoopRunSpecificWithOptions
+                 4235 __CFRunLoopServiceMachPort
+                   4235 mach_msg2_trap

All worker threads (PerfettoTrace, ThreadPool*, Chrome_IOThread, MemoryInfra) idle in mach_msg/kevent64. This is the textbook "Electron app initialized but doing nothing" state. Compatible with an unhandled rejection silenced by a global handler somewhere between app.whenReady() and createWindow().

Network

• lsof -nP -iTCP -p <main_pid>: 0 entries
• lsof -nP -iTCP -p <gpu_helper_pid>: 0 entries
• lsof -nP -iTCP -p <network_helper_pid>: 0 entries

The app never reaches out to any backend. DNS and TCP to api.anthropic.com:443 work fine from the same machine (verified with dig + nc -zv), so this is not a network issue.

Launch log (ELECTRON_ENABLE_LOGGING=1 --enable-logging=stderr --v=1)

The only non-redundant lines emitted before main goes idle:

[VERBOSE1] Display: EVENT screen_mac.mm:467 Display[4] bounds=[0,0 5120x2160], workarea=[0,30 5120x2130], scale=1, rotation=0 external detected
(node) DeprecationWarning: The `punycode` module is deprecated.
[WARNING]  ui/base/resource/resource_bundle.cc:526 locale_file_path.empty() for locale es-ES
[VERBOSE1] components/proxy_config/pref_proxy_config_tracker_impl.cc:462 set chrome proxy config service
[VERBOSE1] content/browser/renderer_host/media/media_stream_manager.cc:1517 MSM::InitializeMaybeAsync
[VERBOSE1] content/browser/first_party_sets/first_party_sets_handler_impl_instance.cc:270 Empty path. Failed initializing First-Party Sets database.
[VERBOSE1] components/viz/service/main/viz_main_impl.cc:86 VizNullHypothesis is disabled (not a warning)

After that, ~150× the same WARNING ui/base/resource/resource_bundle.cc:1266 locale resources are not loaded, and then nothing. No JavaScript errors, no BrowserWindow log entries, no whenReady/activate traces.

Side note: Display[4] with index 4 on a single-display system is unusual but the bounds match the actual hardware; probably a leftover index from a previous configuration. Likely unrelated.

Hypotheses ruled out (saving you time)

Crash data

None. ~/Library/Application Support/Claude/Crashpad/{pending,completed} are empty. The process does not exit.

Diagnostic bundle

A complete diagnostic bundle (sample, processes, AppleScript output, codesign, system_profiler hardware/displays, redacted config.json, launch log, TCP summary) is available as a public Gist:

https://gist.github.com/abkrim/14b4348bde975eb328870d49003b8a87

All sensitive fields (username, machine serial/UUID, OAuth token cache, dxt allowlist cache) have been redacted before publishing.

What would help

1. Confirmation whether 1.5354.0 has a known issue affecting macOS 26.x or systems with ultra-wide 5K displays.
2. A direct download URL (or instructions) for an earlier known-good build (something prior to 2026-04-29 03:39) so I can pin the version while a fix is in flight.
3. Any environment variable / flag that surfaces the unhandled rejection or exception that I'm confident is happening between app.whenReady() and createWindow() in this build.

Severity / impact

Bloqueante for desktop users on this build path. Claude Code CLI works, so I have a workaround for my own use. But anyone whose Squirrel pulled 1.5354.0 on a similar configuration will see a fully unusable desktop app with no error message.

Happy to provide a fresh sample, spindump, or any other artifact you need.