›_ Claude Code Issues
Claude Code Issues / #51087

[BUG]

Resolved 💬 3 comments Opened Apr 20, 2026 by csevenr Closed Apr 23, 2026

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 for Desktop 1.3109.0 launches but never creates a window on macOS 26.5 beta (other same-SDK Electron apps work fine on the same machine)

Environment

  • App: Claude for Desktop 1.3109.0 (com.anthropic.claudefordesktop), built with macosx15.5 SDK
  • OS: macOS 26.5 (build 25F5053d — developer beta), Darwin Kernel 25.5.0
  • Hardware: Apple M3 Pro (arm64)
  • Install source: Fresh download from <https://claude.ai/download>, clean reinstall (userData / Preferences / caches wiped, cfprefsd flushed)
  • CLI for comparison: @anthropic-ai/claude-code@2.1.114 — works fine on the same machine

Symptom

Claude launches (menu bar shows Claude File Edit View Window Help as frontmost), but:

  • Zero BrowserWindows — osascript -e 'tell app "System Events" to tell process "Claude" to count windows' → 0
  • No renderer helper process — only --type=gpu-process and --type=utility --utility-sub-type=network.mojom.NetworkService helpers spawn; the (Renderer) helper is missing
  • ~/Library/Application Support/Claude/ stays completely empty — Chromium never writes Local State, Preferences, cookies DB, etc.
  • Main thread idle in NSApplication run → _DPSNextEvent → mach_msg_trap (init appears to have completed, not blocked)
  • No crash report, no stderr, no system log errors
  • cmd+N, Dock activate, open -a Claude all fail to surface a window

🔑 Hard evidence it's the app, not the environment

The Electron execution environment on this Mac is demonstrably healthy:

| Electron app on same machine | SDK | Works? |
|---|---|---|
| Codex (com.openai.codex) v26.318.11754 | macosx15.5 (identical to Claude) | ✅ 1 window, renderer spawns, userData populated |
| Visual Studio Code 1.116.0 | macosx26.1 | ✅ |
| Homi 0.2.2 | macosx15.5 | ✅ |
| CodeFuse 1.101.0 | macosx14.5 | ✅ |
| Xmind 26.02.04171 | macosx14.5 | ✅ |
| Claude for Desktop 1.3109.0 | macosx15.5 | ❌ 0 windows, no renderer, empty userData |

Codex is the cleanest control: identical macOS 15.5 SDK, identical Electron runtime pattern, runs on the exact same macOS 26.5 beta, and works perfectly. So the issue is something specific to Claude's startup code — not the Electron version, not the SDK, not the macOS beta in general.

Ruled out

| Hypothesis | How ruled out |
|---|---|
| Corrupted install | Clean reinstall; codesign -dv → valid Notarized Developer ID Q6L2SF6YDW; spctl --assess → accepted |
| Stale userData / prefs / stealth-relaunch marker | All wiped; defaults delete + killall cfprefsd |
| Login Items hiding | App not in osascript -e 'tell app "System Events" to get name of every login item'; CLAUDE_AVOID_READING_LOGING_ITEM_SETTINGS=1 env doesn't help |
| Single-instance lock | Source: !en && !requestSingleInstanceLock() — en = process.platform === "darwin" is true, so the condition short-circuits and this path never triggers on macOS |
| Region block | Process opens zero TCP sockets at startup — no network call could have failed |
| System proxy / locale interference | Same behavior with --no-proxy-server, unset HTTP_PROXY, LANG=en_US.UTF-8 --lang=en-US |
| Gatekeeper / quarantine | Cleared; spctl approves |
| SYSTEM_VERSION_COMPAT=1 | No change — still 0 windows |
| Security software / DYLD injection | No antivirus running; no global LaunchAgents with injection; no DYLD_* env vars |
| claude-native-binding.node compatibility | Loads fine via node -e; tested methods (getFrontmostAppInfo, isOtherAppFullscreen, getActiveWindowHandle, getWindowsElevationType, getHcsStatus) all return valid values on macOS 26.5 |

Source-level clue

The main window factory AWt() is gated by show: (EMn || !1) && !ryt() where EMn = !wasOpenedAtLogin. But AWt() is never reached in the first place — no renderer process ever spawns, userData is never written. Control never gets past something earlier in app.on("ready", async () => { ... }).

Best guess for the hang point: one of the async initialization steps before AWt() in the ready handler (e.g. $Mr() installing the app:// protocol handler, or a dynamic import() of an internal @ant/* module) silently never resolves on macOS 26.5 beta — while the same code path resolves fine on older macOS versions, and Codex's ready handler (which doesn't have this specific init sequence) works fine.

Main thread sample (completely idle, not blocked)

Thread_X  DispatchQueue_1: com.apple.main-thread  (serial)
  ElectronMain
  ...
  -[NSApplication run]
  -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:]
  _DPSNextEvent → _DPSBlockUntilNextEventMatchingListInMode
  mach_msg_overwrite → mach_msg2_trap

Running processes after launch:

Claude                                             (main)
Claude Helper --type=gpu-process --user-data-dir=…  ✓
Claude Helper --type=utility --utility-sub-type=…   ✓
Claude Helper (Renderer)                            ✗ MISSING

Expected behavior

Main window appears on launch.

Reproduction

100% reproducible on this machine with Claude Desktop 1.3109.0 downloaded 2026-04-20 from <https://claude.ai/download>. CLI (claude v2.1.114) and OpenAI Codex (also Electron, also macOS 15.5 SDK) work fine on the same machine — so the Electron runtime on macOS 26.5 beta is healthy; the issue is Claude-specific.

What Should Happen?

Claude for Desktop 1.3109.0 launches but never creates a window on macOS 26.5 beta (other same-SDK Electron apps work fine on the same machine)

Environment

  • App: Claude for Desktop 1.3109.0 (com.anthropic.claudefordesktop), built with macosx15.5 SDK
  • OS: macOS 26.5 (build 25F5053d — developer beta), Darwin Kernel 25.5.0
  • Hardware: Apple M3 Pro (arm64)
  • Install source: Fresh download from <https://claude.ai/download>, clean reinstall (userData / Preferences / caches wiped, cfprefsd flushed)
  • CLI for comparison: @anthropic-ai/claude-code@2.1.114 — works fine on the same machine

Symptom

Claude launches (menu bar shows Claude File Edit View Window Help as frontmost), but:

  • Zero BrowserWindows — osascript -e 'tell app "System Events" to tell process "Claude" to count windows' → 0
  • No renderer helper process — only --type=gpu-process and --type=utility --utility-sub-type=network.mojom.NetworkService helpers spawn; the (Renderer) helper is missing
  • ~/Library/Application Support/Claude/ stays completely empty — Chromium never writes Local State, Preferences, cookies DB, etc.
  • Main thread idle in NSApplication run → _DPSNextEvent → mach_msg_trap (init appears to have completed, not blocked)
  • No crash report, no stderr, no system log errors
  • cmd+N, Dock activate, open -a Claude all fail to surface a window

🔑 Hard evidence it's the app, not the environment

The Electron execution environment on this Mac is demonstrably healthy:

| Electron app on same machine | SDK | Works? |
|---|---|---|
| Codex (com.openai.codex) v26.318.11754 | macosx15.5 (identical to Claude) | ✅ 1 window, renderer spawns, userData populated |
| Visual Studio Code 1.116.0 | macosx26.1 | ✅ |
| Homi 0.2.2 | macosx15.5 | ✅ |
| CodeFuse 1.101.0 | macosx14.5 | ✅ |
| Xmind 26.02.04171 | macosx14.5 | ✅ |
| Claude for Desktop 1.3109.0 | macosx15.5 | ❌ 0 windows, no renderer, empty userData |

Codex is the cleanest control: identical macOS 15.5 SDK, identical Electron runtime pattern, runs on the exact same macOS 26.5 beta, and works perfectly. So the issue is something specific to Claude's startup code — not the Electron version, not the SDK, not the macOS beta in general.

Ruled out

| Hypothesis | How ruled out |
|---|---|
| Corrupted install | Clean reinstall; codesign -dv → valid Notarized Developer ID Q6L2SF6YDW; spctl --assess → accepted |
| Stale userData / prefs / stealth-relaunch marker | All wiped; defaults delete + killall cfprefsd |
| Login Items hiding | App not in osascript -e 'tell app "System Events" to get name of every login item'; CLAUDE_AVOID_READING_LOGING_ITEM_SETTINGS=1 env doesn't help |
| Single-instance lock | Source: !en && !requestSingleInstanceLock() — en = process.platform === "darwin" is true, so the condition short-circuits and this path never triggers on macOS |
| Region block | Process opens zero TCP sockets at startup — no network call could have failed |
| System proxy / locale interference | Same behavior with --no-proxy-server, unset HTTP_PROXY, LANG=en_US.UTF-8 --lang=en-US |
| Gatekeeper / quarantine | Cleared; spctl approves |
| SYSTEM_VERSION_COMPAT=1 | No change — still 0 windows |
| Security software / DYLD injection | No antivirus running; no global LaunchAgents with injection; no DYLD_* env vars |
| claude-native-binding.node compatibility | Loads fine via node -e; tested methods (getFrontmostAppInfo, isOtherAppFullscreen, getActiveWindowHandle, getWindowsElevationType, getHcsStatus) all return valid values on macOS 26.5 |

Source-level clue

The main window factory AWt() is gated by show: (EMn || !1) && !ryt() where EMn = !wasOpenedAtLogin. But AWt() is never reached in the first place — no renderer process ever spawns, userData is never written. Control never gets past something earlier in app.on("ready", async () => { ... }).

Best guess for the hang point: one of the async initialization steps before AWt() in the ready handler (e.g. $Mr() installing the app:// protocol handler, or a dynamic import() of an internal @ant/* module) silently never resolves on macOS 26.5 beta — while the same code path resolves fine on older macOS versions, and Codex's ready handler (which doesn't have this specific init sequence) works fine.

Main thread sample (completely idle, not blocked)

Thread_X  DispatchQueue_1: com.apple.main-thread  (serial)
  ElectronMain
  ...
  -[NSApplication run]
  -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:]
  _DPSNextEvent → _DPSBlockUntilNextEventMatchingListInMode
  mach_msg_overwrite → mach_msg2_trap

Running processes after launch:

Claude                                             (main)
Claude Helper --type=gpu-process --user-data-dir=…  ✓
Claude Helper --type=utility --utility-sub-type=…   ✓
Claude Helper (Renderer)                            ✗ MISSING

Expected behavior

Main window appears on launch.

Reproduction

100% reproducible on this machine with Claude Desktop 1.3109.0 downloaded 2026-04-20 from <https://claude.ai/download>. CLI (claude v2.1.114) and OpenAI Codex (also Electron, also macOS 15.5 SDK) work fine on the same machine — so the Electron runtime on macOS 26.5 beta is healthy; the issue is Claude-specific.

Error Messages/Logs

Steps to Reproduce

Claude for Desktop 1.3109.0 launches but never creates a window on macOS 26.5 beta (other same-SDK Electron apps work fine on the same machine)

Environment

  • App: Claude for Desktop 1.3109.0 (com.anthropic.claudefordesktop), built with macosx15.5 SDK
  • OS: macOS 26.5 (build 25F5053d — developer beta), Darwin Kernel 25.5.0
  • Hardware: Apple M3 Pro (arm64)
  • Install source: Fresh download from <https://claude.ai/download>, clean reinstall (userData / Preferences / caches wiped, cfprefsd flushed)
  • CLI for comparison: @anthropic-ai/claude-code@2.1.114 — works fine on the same machine

Symptom

Claude launches (menu bar shows Claude File Edit View Window Help as frontmost), but:

  • Zero BrowserWindows — osascript -e 'tell app "System Events" to tell process "Claude" to count windows' → 0
  • No renderer helper process — only --type=gpu-process and --type=utility --utility-sub-type=network.mojom.NetworkService helpers spawn; the (Renderer) helper is missing
  • ~/Library/Application Support/Claude/ stays completely empty — Chromium never writes Local State, Preferences, cookies DB, etc.
  • Main thread idle in NSApplication run → _DPSNextEvent → mach_msg_trap (init appears to have completed, not blocked)
  • No crash report, no stderr, no system log errors
  • cmd+N, Dock activate, open -a Claude all fail to surface a window

🔑 Hard evidence it's the app, not the environment

The Electron execution environment on this Mac is demonstrably healthy:

| Electron app on same machine | SDK | Works? |
|---|---|---|
| Codex (com.openai.codex) v26.318.11754 | macosx15.5 (identical to Claude) | ✅ 1 window, renderer spawns, userData populated |
| Visual Studio Code 1.116.0 | macosx26.1 | ✅ |
| Homi 0.2.2 | macosx15.5 | ✅ |
| CodeFuse 1.101.0 | macosx14.5 | ✅ |
| Xmind 26.02.04171 | macosx14.5 | ✅ |
| Claude for Desktop 1.3109.0 | macosx15.5 | ❌ 0 windows, no renderer, empty userData |

Codex is the cleanest control: identical macOS 15.5 SDK, identical Electron runtime pattern, runs on the exact same macOS 26.5 beta, and works perfectly. So the issue is something specific to Claude's startup code — not the Electron version, not the SDK, not the macOS beta in general.

Ruled out

| Hypothesis | How ruled out |
|---|---|
| Corrupted install | Clean reinstall; codesign -dv → valid Notarized Developer ID Q6L2SF6YDW; spctl --assess → accepted |
| Stale userData / prefs / stealth-relaunch marker | All wiped; defaults delete + killall cfprefsd |
| Login Items hiding | App not in osascript -e 'tell app "System Events" to get name of every login item'; CLAUDE_AVOID_READING_LOGING_ITEM_SETTINGS=1 env doesn't help |
| Single-instance lock | Source: !en && !requestSingleInstanceLock() — en = process.platform === "darwin" is true, so the condition short-circuits and this path never triggers on macOS |
| Region block | Process opens zero TCP sockets at startup — no network call could have failed |
| System proxy / locale interference | Same behavior with --no-proxy-server, unset HTTP_PROXY, LANG=en_US.UTF-8 --lang=en-US |
| Gatekeeper / quarantine | Cleared; spctl approves |
| SYSTEM_VERSION_COMPAT=1 | No change — still 0 windows |
| Security software / DYLD injection | No antivirus running; no global LaunchAgents with injection; no DYLD_* env vars |
| claude-native-binding.node compatibility | Loads fine via node -e; tested methods (getFrontmostAppInfo, isOtherAppFullscreen, getActiveWindowHandle, getWindowsElevationType, getHcsStatus) all return valid values on macOS 26.5 |

Source-level clue

The main window factory AWt() is gated by show: (EMn || !1) && !ryt() where EMn = !wasOpenedAtLogin. But AWt() is never reached in the first place — no renderer process ever spawns, userData is never written. Control never gets past something earlier in app.on("ready", async () => { ... }).

Best guess for the hang point: one of the async initialization steps before AWt() in the ready handler (e.g. $Mr() installing the app:// protocol handler, or a dynamic import() of an internal @ant/* module) silently never resolves on macOS 26.5 beta — while the same code path resolves fine on older macOS versions, and Codex's ready handler (which doesn't have this specific init sequence) works fine.

Main thread sample (completely idle, not blocked)

Thread_X  DispatchQueue_1: com.apple.main-thread  (serial)
  ElectronMain
  ...
  -[NSApplication run]
  -[NSApplication(NSEventRouting) nextEventMatchingMask:untilDate:inMode:dequeue:]
  _DPSNextEvent → _DPSBlockUntilNextEventMatchingListInMode
  mach_msg_overwrite → mach_msg2_trap

Running processes after launch:

Claude                                             (main)
Claude Helper --type=gpu-process --user-data-dir=…  ✓
Claude Helper --type=utility --utility-sub-type=…   ✓
Claude Helper (Renderer)                            ✗ MISSING

Expected behavior

Main window appears on launch.

Reproduction

100% reproducible on this machine with Claude Desktop 1.3109.0 downloaded 2026-04-20 from <https://claude.ai/download>. CLI (claude v2.1.114) and OpenAI Codex (also Electron, also macOS 15.5 SDK) work fine on the same machine — so the Electron runtime on macOS 26.5 beta is healthy; the issue is Claude-specific.

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.114 (Claude Code)

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

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