[BUG] Claude Desktop App Goes Blank on Latest version

<img width="1217" height="850" alt="Image" src="https://github.com/user-attachments/assets/548b4917-5ebc-4723-a6f8-d2027ecf7a35" />

Opening the same chat thread puts the app into the same frozen and blank screen mode.

I have this issue on Mac M1

Having same issue after upgrading on MacBook Air M4 lol.

same issue but on windows: build 1.11187.4, Windows 11, blank on launch, survives clean reinstall, DevTools won't open.

<img width="1218" height="818" alt="Image" src="https://github.com/user-attachments/assets/8f03e4a8-f7ce-4f10-8a0b-2e651598653b" />

If this is the recurring "renders blank with no error" case on macOS, check ~/Library/Logs/Claude/main.log for this line:

Network Service process gone (reason=killed, exitCode=15) outside app quit — main-process networking is broken until relaunch

If you see it (especially clustered after the app has been backgrounded/idle), the cause is macOS App Nap SIGTERM-reaping the app's helper processes — the renderer survives but loses networking, so it paints blank. Workaround:

defaults write com.anthropic.claudefordesktop NSAppSleepDisabled -bool YES

then fully quit and relaunch. Full write-up and discussion in #68316.

---

Update — confirmed root cause was DNS, not App Nap. The NSAppSleepDisabled tweak only helped the backgrounded case; the network service was still killed within ~1s of a foreground launch. With no crash report, reason=killed means Chromium killed its own hung network service and restarted it.

What was hanging it: my primary DNS resolver was a VPN/MagicDNS address (Tailscale's 100.100.100.100). When that resolver intermittently wedges, the net service's blocking DNS stalls and Chromium reaps it → blank renderer. Fix that fully stopped it: point DNS back at a normal resolver — for Tailscale, tailscale set --accept-dns=false (so the OS uses the LAN/public resolver instead of 100.100.100.100).

If you're on this issue: run scutil --dns and check whether a VPN/MagicDNS server is your primary nameserver. Full write-up in #68316.

---

Update — confirmed root cause was DNS, not App Nap. The NSAppSleepDisabled tweak only helped the backgrounded case; the network service was still killed within ~1s of a foreground launch. With no crash report, reason=killed means Chromium killed its own hung network service and restarted it.

What was hanging it: my primary DNS resolver was a VPN/MagicDNS address (Tailscale's 100.100.100.100). When that resolver intermittently wedges, the net service's blocking DNS stalls and Chromium reaps it → blank renderer. Fix that fully stopped it: point DNS back at a normal resolver — for Tailscale, tailscale set --accept-dns=false (so the OS uses the LAN/public resolver instead of 100.100.100.100).

If you're on this issue: run scutil --dns and check whether a VPN/MagicDNS server is your primary nameserver. Full write-up 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.