[BUG] Claude Desktop 1.30096.5 hangs before creating a window on macOS

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 launches but never creates a window. Its main process remains running and the app must be force-quit. No renderer process is created.

This started immediately after the app updated from 1.28929.0 to 1.30096.5. The same Mac and account worked normally on 1.28929.0.

What Should Happen?

Claude Desktop should create its main window and renderer process.

Error Messages/Logs

A sample of the main thread repeatedly stops in:
-[SMAppService status]
com.apple.ServiceManagement / XPC calls

The process tree contains the main process, crashpad, GPU, network, and Node utility processes, but no renderer. The app log stops after resolving login-shell environment variables.

Steps to Reproduce

1. On macOS 15.7.7 (Apple Silicon), install and open Claude Desktop 1.30096.5.
2. Launch /Applications/Claude.app.
3. Wait for the app window.
4. Observe that the app remains running with no window or renderer and does not recover.

Troubleshooting already tried:

• Fresh reinstall.
• Removed or renamed Cache, Code Cache, and GPUCache.
• Tested with a fresh isolated profile.
• Tested with GPU disabled.
• Verified network, disk, memory, and code signature.
• Removed Claude from saved macOS relaunch items.
• sfltool resetbtm was attempted, but the command hung and the BTM registry remained unchanged. Restarting backgroundtaskmanagementd was blocked by SIP.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.28929.0 (Claude Desktop)

Claude Code Version

1.30096.5 (Claude Desktop)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Hypothesis: the startup path calls Electron app.getLoginItemSettings().wasOpenedAtLogin before BrowserWindow creation. On this machine that call blocks in SMAppService, so the renderer is never created. A timeout or safe fallback around the login-item query may prevent the startup deadlock.

No crash report was produced because the main process remains hung.