[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.
60 Comments
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:
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
beforeQuithandler may be eating subsequent Cmd+Q events entirely, and only the Dock's quit mechanism (which may use a different code path likeapp.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:
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
beforeQuitis not just delaying quit, but putting the app into an invalid state where it: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 shell``
ps auxwww | grep -i claude`` _after_ quit: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:
Same issue with MacOS 15.7.3
Same issue
It seems they’re on holiday, so we’ll need to wait. Hopefully it’s a bug and not by design 😆
<img width="225" height="225" alt="Image" src="https://github.com/user-attachments/assets/2787a513-1c15-4839-85a8-1abe6534c22d" />
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: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
Dear all,
I guess my experience can be described here.
I’m trying to get Blender to interact with Claude via the Blender MCP server.
Fyi, im on Mac M1 Max
Mac OS Sequoia 15.7.2
I follow theses instructions step by step
https://github.com/ahujasid/blender-mcp
As I'm a beginner in coding, I understood that I needed to install Homebrew via my Mac's Terminal to activate the UV package manager. The installation seemed to work fine, with Xcode Command Line Tools installed.
At the end of the installation, I was prompted to add these two lines of code.
Done.
Finally, I opened Blender, and the addon.py installation is OK. I connected to the Blender MCP server into Blender 5.0.
However, when I open Claude and modify the developer configuration by changing the claude_desktop_config.json file via Visual Studio Code, I enter the following data:
{
"mcpServers": {
"blender": {
"command": "uvx",
"args": [
"blender-mcp"
]
}
}
}
I save the new laude_desktop_config.json file
I'm trying to close Claude and restart it, but Claude is unresponsive.
If I force quit and restart it, the server is configured correctly, but an error message appears, and interaction with Blender doesn't work.
Thank you in advance to anyone who can help me. I remain at your disposal for any further information.
Peace
Confirming this issue on:
Same behavior: Cmd+Q closes window but app stays running in Dock. End up force quitting. Have to do this every time I want to close the app.
Hi remi-media,
Please open a new, different bug report for this. Please do not tag on to this or other bug reports for unrelated issues.
You can make it really easy on yourself by asking Claude to help you through the process of reporting your bug. It will definitely help to inform Claude of exactly what the bug report template is asking for.
Thank you,
+Morgan Catlin
To Everyone,
Thank You for adding your reports and details!
Claude suspected it was Electron's doing and your input will absolutely help nail this down once Anthropic takes notice.
With Much Appreciation!,
+Morgan Catlin
Hi Morgan,
My apologies, I'm new to GitHub, I understand I wasn't specifically on the topic.
Thank you for your advice.
Regards,
Rémi
I can't find a way to up-vote this other than adding my own comment, so here you go.
This is an egregious break of OS-level "How to quit an app" semantics. I deal with seniors that have a hard enough time dealing with apps WHEN THEY WORK, let alone trying to special-case by quitting from the dock. Breaking standard pathways like this is nearly impossible to work around with that user community.
Im on macos 26.2 and this bug really sucks. It nervs more and more, because of this i dont want to use even the mac app.
99% of the time im using chatgpt, just because of this stupid bug.
The macapp is horrible anyway, the chatgpt app is a lot better.
How a AI-Generated app is so much worse, one that uses a model especially meant for coding compared to Chatgpt?
A new angle potentially to this, thanks to Claude. I too asked Claude to help try to debug this. The following is the report of "our" effort. Perhaps others can see if this is relevant to them. I don't know if it will work, but I am attaching the .sh script that Claude wrote to detect it (which has a small bug it appears, but after the log is produced).
Additional Reproduction + Process Sample + Potential Root Cause
I can independently confirm this bug on:
Process Sample During Zombie State
I captured a 3-second
sampleof the main process while in the zombie state. The main thread is stuck in the macOS event loop waiting for events:The app is sitting in
mach_msg2_trapwaiting for events, but withreadyForQuit=trueand no windows. It never callsapp.quit()to actually terminate. This confirms the OP's hypothesis.Potential Root Cause: "Claude in Chrome" MCP runs even when disabled
My logs show Chrome MCP activity during the zombie state:
Here's what's interesting: I have:
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.anthropic.claude_desktop.jsondoes not exist)Yet on every app launch, the logs show:
The Chrome MCP initialization and cleanup runs on every launch/quit regardless of whether the feature is enabled or the extension exists. The
mcp-shutdowncleanup is running against a phantom or partially-initialized state.Double Initialization Also Confirmed
Hypothesis
The bug may not just be a missing
app.quit()call, but specifically related to the Chrome MCP lifecycle:mcp-shutdowncleanup runs against this phantom statereadyForQuitgets set, but the actual quit never firesapp.terminate()) that bypasses this issueSuggested Investigation
The Anthropic team should check:
mcp-shutdownproperly handling the case where Chrome MCP was never fully established?Environment Details
watch_claude_zombie_v2.sh
the mac app has been very unstable for the past 1-2months, but this bug really unnerves me, had to come here and echo this as well
What a shame for a company making billions not able to write 2 lines of code that work.
Seems unlikely a company making a coding tool would forget to add
app.quit()The bug isn't a missing line of code. It's a false assumption about Electron's event model.
The Broken Assumption
User presses Cmd+Q
→ beforeQuit event fires
→ preventDefault() called
→ Async cleanup scheduled
→ Flag set: readyForQuit = true
→ [Some time later] app.quit() called
Expected result: Clean quit
Actual result: Zombie state
The assumption: "If I prevent this event and then call quit() later, Electron will know I'm ready."
The reality: preventDefault() consumes the event. It tells Electron "the app is handling its own quit sequence." When app.quit() is called later, Electron treats it as a new quit request—not a continuation of the original one. But the original quit request has already been consumed and dismissed.
"That's not an oversight. That's a diagnostic.
What It Reveals
The inversion of attention: The team has clearly invested heavily in forward-flow event handling. Look at 2.0.64: "Agents and bash commands can run asynchronously and send messages to wake up the main agent." They solved coordination in the forward direction—async operations that reach back to the main thread.
The quit bug is the reverse: async cleanup that needs to reach backward to the OS lifecycle and say "I'm ready now." That pattern is less sophisticated than what surrounds it. It looks like it was built with an older mental model and never revisited as the rest of the system matured.
The assumption that got wrong: Someone built a contract that assumes "preventDefault() + async cleanup + later quit() = controlled shutdown." That's reasonable defensive thinking in isolation. But it's built on a false assumption about what's actually load-bearing in Electron's event model.
Meanwhile, the app has invested in hooks, plugins, MCP servers, session recovery, state persistence. All sophisticated event coordination. But the quit sequence is fighting the framework instead of working with it..."
Hi from Anthropic! Thanks for the report - we're on it.
@felixrieseberg please make a native app, forget electron 🙏🏻
I know a great tool they can use to build it.
Yeah, seeing the same thing - I tried uninstall, completely wipe ~/Library/Application Support/Claude, just to see if a clean re-install helped - no dice.
Hi Felix!
Thank You for letting us know this issue has attention and for keeping us updated!
Cheers!
+Morgan Catlin
I have gotten used to manually quit from the dock icon, there's nothing else we can do until they fix it.
I do not see any other issues with the stability of the app, using it very successfully so far
Same for me.
+1. This happens every time I quit Claude desktop on macOS 26.2
Same issue, 26.2. I made the mistake of going through the Fin AI support flow in Claude and wasted 15m of my life. Looking forward to fix.
I can confirm this bug and it appears tied to specific macOS versions.
Tested on two Apple-Silicon Macs:
• macOS Sequoia 15.6 → Cmd+Q works correctly
• macOS Sequoia 15.7.3 → Cmd+Q broken (app enters zombie state)
• macOS Tahoe 26.2 → Cmd+Q broken (same behavior)
On one machine the issue appeared immediately after upgrading from 15.6 to 15.7.3. On the second machine (Tahoe) it was present from first launch.
Behavior matches the original report exactly:
• Cmd+Q closes all windows but the app remains in the Dock
• All keyboard shortcuts stop responding (Cmd+Q, Cmd+N, Cmd+Option+I, etc.)
• Only Force Quit or Dock context menu works
• All 7 Claude processes remain running
Logs are identical to other reports:
[info] Successfully ran all onQuitCleanup handlers, marking readyForQuit
After this, the app never terminates.
Current workaround is Force Quit.
Getting rid of Electron altogether would be the best, though.
2026 and still using technology from the stone age ... where do all the money go I wonder. For sure not in a working native app.
Hi all, thanks for your patience. We've shipped a fix in the latest release - if you update (Claude > Check for updates), restart the app (via the dock icon > "quit"), this issue should be resolved.
The update didn't work for me (perhaps of the faulty state on exit it couldn't be performed) but uninstalling the app and downloading it again from the web worked. Thank you so much! 🙏 🎉
I'm seeing the same - had to manually remove it, then install from the download page, but now I can quit! Thanks!
Claude on MacOs was closed, I opened it, updated it then still impossible to quit during update, kill the process and automatically re-opened it. now Quit works
Woohoo! Update fixed this for me.
Update worked fine. Yes, yes, had to Force Quit one last time to exit and relaunch Claude 1.0.2768, but after that, good to go on my machine.
@felixrieseberg & @joan-anthropic,
Thank You so very much for fixing this bug! The fix is working for me as well.
Yes, I also had to:
Due to the nature of the original bug, I suspect we'll have either (a) a bunch of repeat attempts to run the update before it takes affect, or (b) re-installation as an easier force-update strategy.
I intend to leave this issue open for a few more days to give everyone a chance to get updated and fixed -- let me know if this is a problem. Please continue to focus responses on this particular issue.
Thank You again to Joan and Felix!!
Going to close this issue. @hire-mlcatlin if people open new issues I'll take care of it. Thanks so much for reporting!
@amorriscode There is still a bug left connected to this issue. If Claude is running when I try to shutdown my Mac, it is not able to close Claude, and I get a message saying that shutdown was prevented due to Claude. After that, it is no longer possible to shutdown Claude properly again. Running version 1.0.2768.
@steinrr Would you please start a new bug report, reference this bug report, and get Claude’s assistance writing up the details?
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.