[BUG] Claude Desktop macOS requires quitting twice (Cmd+Q → wait → system Dock pop-up menu Quit)
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?
Note: This is a Claude Desktop bug, not Claude Code CLI.
Claude Desktop on macOS enters a zombie state after pressing Cmd+Q:
- Press Cmd+Q → Window closes but app keeps running (visible in Dock)
- App becomes completely non-functional:
- Cmd+Q no longer responds AT ALL
- Cannot open new conversations
- Cannot open Settings
- Cannot spawn any new windows
- Clicking Dock icon does nothing
- ONLY way to quit: Right-click Dock icon → "Quit" from context menu
The app is stuck in a broken state where it has closed all windows, disabled normal quit handling, and cannot recover or terminate normally. Only the Dock context menu quit (which likely uses a different code path) can kill the process.
Additionally, app initialization runs twice on every launch (two identical "Starting app" log entries at the same timestamp).
What Should Happen?
Pressing Cmd+Q once should quit the app cleanly. If cleanup is needed, the app should either:
- Complete cleanup and auto-quit, OR
- Remain functional (windows open, responsive) until cleanup completes
The app should NEVER enter a non-functional zombie state where it's running but completely unresponsive to user interaction.
Error Messages/Logs
From ~/Library/Logs/Claude/main.log:
=== FIRST Cmd+Q (app enters zombie state) ===
2025-12-21 02:07:25 [info] beforeQuit handler fired, going down
2025-12-21 02:07:25 [info] willQuit handler is not yet run, preventing quit and cleaning things up
2025-12-21 02:07:25 [info] Starting onQuitCleanup
2025-12-21 02:07:25 [info] Running onQuitCleanup: mcp-shutdown
2025-12-21 02:07:25 [info] Running onQuitCleanup: quick-entry-cleanup
2025-12-21 02:07:25 [info] Running onQuitCleanup: prototype-cleanup
2025-12-21 02:07:25 [info] Successfully run onQuitCleanup: quick-entry-cleanup
2025-12-21 02:07:25 [info] Successfully run onQuitCleanup: prototype-cleanup
2025-12-21 02:07:25 [info] Successfully run onQuitCleanup: mcp-shutdown
2025-12-21 02:07:25 [info] Successully ran all onQuitCleanup handlers, marking readyForQuit
[APP NOW IN ZOMBIE STATE - Cmd+Q ignored, no windows, completely unresponsive]
=== DOCK RIGHT-CLICK QUIT (only way to actually quit) ===
2025-12-21 02:07:30 [info] beforeQuit handler fired, going down
2025-12-21 02:07:30 [info] willQuit handler is ready for quit, so quitting
=== ALSO: Double initialization on every launch ===
2025-12-21 02:02:56 [info] Starting app { appVersion: '1.0.2339', ... }
2025-12-21 02:02:56 [info] Starting app { appVersion: '1.0.2339', ... }
Steps to Reproduce
- Install Claude Desktop on macOS (tested on Tahoe 26.2, arm64)
- Launch the app
- Press Cmd+Q to quit
- Observe: Window closes but app remains in Dock
- Try ANY of these - ALL FAIL:
- Cmd+Q again → No response
- Click Dock icon → Nothing happens
- Cmd+N for new conversation → Nothing
- Try to open Settings → Nothing
- Right-click Dock icon → Select "Quit" → App finally terminates
The app is in a completely broken zombie state after step 4. Only Dock context menu quit works.
Verified on:
- Fresh install after complete uninstall (removed all ~/Library data)
- With and without MCP servers configured
- Multiple versions (1.0.1307, 1.0.2339)
Claude Model
None
Is this a regression?
I don't know
Last Working Version
Unknown - bug present in all versions I've tested (1.0.1307, 1.0.2339)
Claude Code Version
N/A - This bug is in Claude Desktop app, not Claude Code CLI. Claude Desktop version: 1.0.2339
Platform
Other
Operating System
macOS
Terminal/Shell
Other
Additional Information
Environment
- macOS Tahoe 26.2 (arm64 / Apple Silicon)
- Claude Desktop 1.0.2339
- Node.js 22.21.1 (bundled with app)
Severity: HIGH
This completely breaks the standard macOS app lifecycle. Users cannot:
- Quit normally via Cmd+Q
- Continue using the app after attempting to quit
- Do anything except force-quit via Dock context menu
Root Cause Analysis
The Electron beforeQuit handler:
- Closes all windows
- Runs cleanup
- Sets
readyForQuitflag - Does NOT call
app.quit() - Does NOT keep app in usable state
- Apparently blocks/ignores subsequent Cmd+Q events entirely
The app is left in an invalid state: windowless, non-functional, but still running. Only the Dock's quit mechanism (possibly using app.terminate() or similar) can kill it.
Suggested Fix
Either:
A) Call app.quit() immediately after cleanup completes, OR
B) Don't close windows until actually quitting, OR
C) Keep app functional until quit completes
Related
- Similar double-execution pattern reported in Claude Code hooks: #3465
- This may share root cause with the double "Starting app" initialization
Filing Note
I know this template is for Claude Code CLI, but web search indicated Claude Desktop bugs should be filed here with "external" label. Please tag appropriately.
Correction: Second quit MUST be via Dock context menu
I need to correct the bug description. The second quit cannot be Cmd+Q again—it specifically requires:
- Press Cmd+Q → App appears to close (window gone) but process remains running
- Right-click Dock icon → Select "Quit" from context menu
Pressing Cmd+Q a second time does NOT work. Only the Dock right-click → Quit method terminates the app after the initial Cmd+Q.
This suggests the beforeQuit handler may be eating subsequent Cmd+Q events entirely, and only the Dock's quit mechanism (which may use a different code path like app.terminate() or similar) can actually kill the process.
Apologies for the confusion in the original report.
Update: App enters completely broken "zombie state" after first Cmd+Q
This bug is more severe than initially described. After pressing Cmd+Q once:
What happens:
- Main window closes
- App process remains running (visible in Dock)
- App becomes completely non-functional:
- Cmd+Q no longer responds at all
- Cannot open new conversations
- Cannot open Settings
- Cannot spawn any new windows
- Clicking Dock icon does nothing useful
Only recovery:
Right-click Dock icon → "Quit" from context menu
Impact:
This isn't just a "press quit twice" annoyance—the app becomes a zombie process that's completely unresponsive to normal user interaction. The standard macOS app lifecycle is completely broken.
This suggests beforeQuit is not just delaying quit, but putting the app into an invalid state where it:
- Has closed all windows
- Has disabled normal quit handling
- Cannot recover to a usable state
- Only responds to forced termination via Dock
Claude literally wrote this bug report and fouled up the original description.
I made Claude update the body of the original bug report.
Came to report the same. Thanks.
"Force quit" (Apple Menu -> Force Quit...) also works to kill Claude definitively (of course).
Output from shellps auxwww | grep -i claude after quit:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
doug 39832 9.3 0.4 1891065040 269616 ?? S 10:00PM 0:03.37 /Applications/Claude.app/Contents/MacOS/Claude
doug 39845 0.1 0.6 1890794720 433664 ?? S 10:01PM 0:02.69 /Applications/Claude.app/Contents/Frameworks/Claude Helper (Renderer).app/Contents/MacOS/Claude Helper (Renderer) --type=renderer --user-data-dir=/Users/doug/Library/Application Support/Claude --secure-schemes=sentry-ipc --bypasscsp-schemes=sentry-ipc --cors-schemes=sentry-ipc --fetch-schemes=sentry-ipc --app-path=/Applications/Claude.app/Contents/Resources/app.asar --enable-sandbox --lang=en-US --num-raster-threads=4 --enable-zero-copy --enable-gpu-memory-buffer-compositor-resources --enable-main-frame-before-activation --renderer-client-id=7 --time-ticks-at-unix-epoch=-1766339674579378 --launch-time-ticks=11186261832 --shared-files --field-trial-handle=1718379636,r,12268896909618004120,14992523860770622580,262144 --enable-features=DocumentPolicyIncludeJSCallStacksInCrashReports,PdfUseShowSaveFilePicker,ScreenCaptureKitPickerScreen,ScreenCaptureKitStreamPickerSonoma --disable-features=MacWebContentsOcclusion,ScreenAIOCREnabled,SpareRendererForSitePerProcess,TimeoutHangingVideoCaptureStarts --variations-seed-version --seatbelt-client=18
doug 39842 0.0 0.1 1890484768 98976 ?? S 10:00PM 0:00.16 /Applications/Claude.app/Contents/Frameworks/Claude Helper (Renderer).app/Contents/MacOS/Claude Helper (Renderer) --type=renderer --user-data-dir=/Users/doug/Library/Application Support/Claude --secure-schemes=sentry-ipc --bypasscsp-schemes=sentry-ipc --cors-schemes=sentry-ipc --fetch-schemes=sentry-ipc --app-path=/Applications/Claude.app/Contents/Resources/app.asar --enable-sandbox --lang=en-US --num-raster-threads=4 --enable-zero-copy --enable-gpu-memory-buffer-compositor-resources --enable-main-frame-before-activation --renderer-client-id=6 --time-ticks-at-unix-epoch=-1766339674579378 --launch-time-ticks=11185180821 --shared-files --field-trial-handle=1718379636,r,12268896909618004120,14992523860770622580,262144 --enable-features=DocumentPolicyIncludeJSCallStacksInCrashReports,PdfUseShowSaveFilePicker,ScreenCaptureKitPickerScreen,ScreenCaptureKitStreamPickerSonoma --disable-features=MacWebContentsOcclusion,ScreenAIOCREnabled,SpareRendererForSitePerProcess,TimeoutHangingVideoCaptureStarts --variations-seed-version --seatbelt-client=67
doug 39837 0.0 0.1 469377008 76960 ?? S 10:00PM 0:00.35 /Applications/Claude.app/Contents/Frameworks/Claude Helper.app/Contents/MacOS/Claude Helper --type=utility --utility-sub-type=network.mojom.NetworkService --lang=en-US --service-sandbox-type=network --user-data-dir=/Users/doug/Library/Application Support/Claude --secure-schemes=sentry-ipc --bypasscsp-schemes=sentry-ipc --cors-schemes=sentry-ipc --fetch-schemes=sentry-ipc --shared-files --field-trial-handle=1718379636,r,12268896909618004120,14992523860770622580,262144 --enable-features=DocumentPolicyIncludeJSCallStacksInCrashReports,PdfUseShowSaveFilePicker,ScreenCaptureKitPickerScreen,ScreenCaptureKitStreamPickerSonoma --disable-features=MacWebContentsOcclusion,ScreenAIOCREnabled,SpareRendererForSitePerProcess,TimeoutHangingVideoCaptureStarts --variations-seed-version --seatbelt-client=36
doug 39835 0.0 0.1 469400544 99712 ?? S 10:00PM 0:00.71 /Applications/Claude.app/Contents/Frameworks/Claude Helper (GPU).app/Contents/MacOS/Claude Helper (GPU) --type=gpu-process --user-data-dir=/Users/doug/Library/Application Support/Claude --gpu-preferences=UAAAAAAAAAAgAAAEAAAAAAAAAAAAAAAAAABgAAMAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAA --shared-files --field-trial-handle=1718379636,r,12268896909618004120,14992523860770622580,262144 --enable-features=DocumentPolicyIncludeJSCallStacksInCrashReports,PdfUseShowSaveFilePicker,ScreenCaptureKitPickerScreen,ScreenCaptureKitStreamPickerSonoma --disable-features=MacWebContentsOcclusion,ScreenAIOCREnabled,SpareRendererForSitePerProcess,TimeoutHangingVideoCaptureStarts --variations-seed-version --seatbelt-client=32
doug 39834 0.0 0.0 468989328 9152 ?? S 10:00PM 0:00.01 /Applications/Claude.app/Contents/Frameworks/Electron Framework.framework/Helpers/chrome_crashpad_handler --no-rate-limit --monitor-self-annotation=ptype=crashpad-handler --database=/Users/doug/Library/Application Support/Claude/Crashpad --url=https://f.a.k/e --annotation=_productName=Claude --annotation=_version=1.0.2339 --annotation=plat=OS X --annotation=prod=Electron --annotation=ver=37.10.3 --handshake-fd=17
Same. I wonder how this is not affecting more users.
Are you using DNS blocking by any chance? statsig.claude.ai? https://code.claude.com/docs/en/data-usage. Could this be a cause for this?
I have the same problem - seems like this happened in one of the recent updates.
I think it kinda went into the Chrome-like state. 99% it's an electron app. And Chrome requires pressing Cmd+Q twice to quit. Here, it kinda quits but doesn't on first Cmd+Q. If you observe the menu bar at top of screen carefully, on the first Cmd+Q it still says Claude. Which means that it kinda only killed the UI, and to finish it off it waits for the second Cmd+Q.
In my case I can press Cmd-Q as often as I like - it does not quit.
Right. Same for me now 😅 I wonder if I imagined it 🤣
Came here to report this, noticed it a bit ago! Interestingly enough, while in the quit zombie state, it's still possible to pull up the quick access as well as the voice quick access menus, with full input available. Submitting closes it without anything else happening, though.
I'm experiencing the same issue on Windows 11. Even after closing the window, the process remains active (zombie process) and the System Tray icon becomes unresponsive. I cannot interact with the tray icon and have to force quit the app via Task Manager.
Same here on MacOS 26.2 Client: Claude 1.0.2339 (1782e2)
Hopefully this isn't foreshadowing, haha ;)
This bug also impacts:
- Claude 1.0.2339 (1782e2)
- MacOS 26.1 (25B78)
Same issue with MacOS 15.7.3
Same issue
- MacOS 26.1 25B78
- Claude 1.0.2339 (1782e2)
It seems they’re on holiday, so we’ll need to wait. Hopefully it’s a bug and not by design 😆
same bug on macOS 26.2. it's a pain in the butt merry xmas 🎄BTW
Sent @amorriscode at Anthropic a video a few days back to report this.
It could actually be an Electron issue (Claude desktop is built with Electron).
Same here - macOS 26.1.
Seeing this also.
When run from the commandline (/Applications/Claude.app/Contents/MacOS/Claude), I got some error messages: first I attempted to quit (nothing was logged). Next I clicked on the Claude icon in my Dock (macos 26.2) and I got a lot of errors printed to stdout:
WebContents #4 called ipcRenderer.sendSync() with '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.hybrid_$_DesktopIntl_$_getInitialLocale' channel without listeners.
Error occurred in handler for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.hybrid_$_DesktopIntl_$_requestLocaleChange': Error: No handler registered for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.hybrid_$_DesktopIntl_$_requestLocaleChange'
at Session.<anonymous> (node:electron/js2c/browser_init:2:107366)
at Session.emit (node:events:519:28)
Error occurred in handler for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_Account_$_setAccountDetails': Error: No handler registered for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_Account_$_setAccountDetails'
at Session.<anonymous> (node:electron/js2c/browser_init:2:107366)
at Session.emit (node:events:519:28)
Error occurred in handler for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_QuickEntry_$_setRecentChats': Error: No handler registered for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_QuickEntry_$_setRecentChats'
at Session.<anonymous> (node:electron/js2c/browser_init:2:107366)
at Session.emit (node:events:519:28)
Error occurred in handler for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_WindowControl_$_setThemeMode': Error: No handler registered for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_WindowControl_$_setThemeMode'
at Session.<anonymous> (node:electron/js2c/browser_init:2:107366)
at Session.emit (node:events:519:28)
Error occurred in handler for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_WindowState_$_getFullscreen': Error: No handler registered for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_WindowState_$_getFullscreen'
at Session.<anonymous> (node:electron/js2c/browser_init:2:107366)
at Session.emit (node:events:519:28)
Error occurred in handler for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_WindowState_$_getFullscreen': Error: No handler registered for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_WindowState_$_getFullscreen'
at Session.<anonymous> (node:electron/js2c/browser_init:2:107366)
at Session.emit (node:events:519:28)
Error occurred in handler for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_QuickEntry_$_setRecentChats': Error: No handler registered for '$eipc_message$_a1508b9a-ba82-4408-83ed-cc47e955c095_$_claude.web_$_QuickEntry_$_setRecentChats'
at Session.<anonymous> (node:electron/js2c/browser_init:2:107366)
at Session.emit (node:events:519:28)
IPC race condition! This would explain why things like quit don't work -- the renderer has become unattached and can't respond to keyboard commands anymore.
The dock quit trick will work as the dock is sending SIGTERM to the process.
(This response written by Claude ;) )
same bug on macOS Tahoe 26.1 🙁
Same issue on Windows (v1.0.2339)
Confirming this affects Windows too - right-click tray → Quit closes the window but leaves claude.exe processes running.
Root cause: This is https://github.com/electron/electron/issues/33643. The new async cleanup in v1.0.2339 calls event.preventDefault() in the will-quit handler, then tries app.quit() after cleanup finishes. Electron ignores the second app.quit() call.
Logs show cleanup succeeds: Successully ran all onQuitCleanup handlers, marking readyForQuit But no second beforeQuit fires - app stays running.
Fix per Electron issue: Use setTimeout(() => app.quit(), 0) or app.exit() after cleanup.
Workaround: taskkill /IM claude.exe /F
v1.0.1768 works correctly (uses sync cleanup without preventDefault).
Same on Tahoe 26.2 - Claude 1.0.2339 (1782e2) 2025-12-16T19:35:52.000Z