Claude desktop app hangs indefinitely on Exit/Restart — process never terminates after completing full quit-cleanup sequence

Environment:

• Claude desktop app v1.26832.0 (Electron 42.7.0)
• macOS 26.5.2 (Build 25F84), Apple Silicon
• Reproduces across multiple networks: home wifi, separate work network, mobile hotspot, and a school network with an SSL-inspecting proxy — not network-dependent

Steps to reproduce:

1. Use the app normally (chat, or a Cowork/agent session)
2. Click Exit, or click "Restart" on a session
3. App becomes unresponsive ("Not Responding" in macOS), requires force-quit

Evidence (main.log excerpt):

Successfully run onQuitCleanup: local-session-flush
Successfully run onQuitCleanup: flush-web-storage
Successfully run onQuitCleanup: cowork-vm-shutdown
Successully ran all onQuitCleanup handlers, marking readyForQuit
beforeQuit: handler is ready for quit, so quitting
willQuit: handler is ready for quit, so quitting
[heavy-work] worker exited (0); will refork on next request

No further log output after this. Process (Contents/MacOS/Claude) confirmed still running 7+ minutes later at 0% CPU — not busy, just never exits. All cleanup/flush steps report success before the hang, so no data appears to be lost, but the OS-level process persists indefinitely and requires SIGKILL.

Suspected cause: A background connection not covered by the onQuitCleanup handler list — most likely the "Remote Control" / sessions-bridge poller (reconnects to claude.ai/code roughly every 17s) — may be holding the process open after Electron's quit() is called, since none of the logged cleanup steps reference stopping it.

Secondary, related finding: On networks with SSL-inspecting proxies (e.g. school/corporate), the transport:sdk component used by sessions-bridge fails with unable to get local issuer certificate and retries in a loop, even after the custom CA is trusted in the user's login keychain and NODE_EXTRA_CA_CERTS is set to the app's own generated CA bundle — while other app components (downloader, Chromium net stack) trust the same custom CA fine on the same network. This suggests the embedded SDK subprocess uses a separate/hardcoded CA trust path that doesn't respect either the OS trust store or NODE_EXTRA_CA_CERTS.

Happy to provide full logs if useful.