[BUG] mac OS 26.2 shutdown failures

Resolved 💬 3 comments Opened Feb 1, 2026 by jaygamel Closed Feb 5, 2026

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?

My mac 2020 intel running os 26.2 fails to shut down. claude has examined logs and written this report to submit.

bug-report-desktop-quit.md

What Should Happen?

Computer should shut down

bug-report-desktop-quit.md

Error Messages/Logs

Mac failed to shut down.

Steps to Reproduce

Automatic shutdown initiates at 11:45 p.m. and panics after 30 second all quit limit then fails to continue and shutdown.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.1.1520 (48ced7)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

[BUG] Claude Desktop fails to quit — process survives as windowless zombie, Quick Entry errors on "Object has been destroyed"

---

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 Desktop

---

What's Wrong?

Claude Desktop appears to quit (window disappears, no dock icon activity) but the process remains alive with zero visible windows. Subsequent attempts to open a new window fail silently. Quick Entry hotkey still fires but every submission throws TypeError: Object has been destroyed because the BrowserWindow was destroyed during the quit cleanup but the process never actually terminated. The only recovery is killall Claude or Activity Monitor.

The quit sequence runs cleanly through all onQuitCleanup handlers and logs beforeQuit: handler is ready for quit, so quitting — but the willQuit event never fires, which is the final event before Electron terminates the process. Compare to a successful quit from the same session ~6 hours earlier where willQuit fires as expected.

---

Environment

  • Claude Desktop version: 1.1.1520 (commit 48ced7a78a74c4c1b03d1dab181d1b0dc21d8fc8)
  • Operating System: macOS Tahoe 26.2 (Darwin kernel 25.2.0)
  • Hardware: Intel Core i5-10600 (12 cores), 64 GB RAM
  • Electron version: 37.10.3
  • Chrome/V8: 138.0.7204.251 / 13.8.258.32-electron.0

---

Steps to Reproduce

  1. Launch Claude Desktop on macOS (Intel)
  2. Have MCP servers connected (mcp-registry, Claude in Chrome — both logged as connection-requested at 06:06:40)
  3. Quit the app (Cmd+Q or window close)
  4. Observe: window disappears, but process is still running
  5. Attempt to open Claude again — nothing happens
  6. Press Quick Entry hotkey — overlay appears, but submitting a prompt throws TypeError: Object has been destroyed and no chat window opens

---

Expected Behavior

After beforeQuit cleanup completes and readyForQuit is marked, willQuit should fire and the process should terminate. A fresh launch should then open a new window normally.

---

Actual Behavior

willQuit never fires. The process persists with 0 windows but 2 live WebContents (the find-in-page overlay and the last chat URL). Quick Entry's submit path crashes because it tries to hand off to the already-destroyed BrowserWindow.

---

Log Evidence

Failed quit — Feb 1, 06:15:33 (main.log)

The cleanup chain runs identically to a successful quit, but stops after the second beforeQuit. No willQuit follows. Next log entry is 3.5 minutes later when Quick Entry fires:

2026-02-01 06:15:33 [info] beforeQuit: handler fired, going down
2026-02-01 06:15:33 [info] beforeQuit: handler is not yet run, preventing quit and cleaning things up
2026-02-01 06:15:33 [info] Starting onQuitCleanup, hiding windows
2026-02-01 06:15:33 [info] Running onQuitCleanup: launch-cleanup
2026-02-01 06:15:33 [info] Running onQuitCleanup: mcp-shutdown
2026-02-01 06:15:33 [info] Running onQuitCleanup: local-mcp-server-cleanup
2026-02-01 06:15:33 [info] [LocalMcpServerManager] Closing all (0 servers)
2026-02-01 06:15:33 [info] Running onQuitCleanup: session-health-tracking
2026-02-01 06:15:33 [info] Running onQuitCleanup: quick-entry-cleanup
2026-02-01 06:15:33 [info] Running onQuitCleanup: feedback-window-cleanup
2026-02-01 06:15:33 [info] Running onQuitCleanup: prototype-cleanup
2026-02-01 06:15:33 [info] Running onQuitCleanup: remote-server-cleanup
2026-02-01 06:15:33 [info] Successfully run onQuitCleanup: launch-cleanup
2026-02-01 06:15:33 [info] Successfully run onQuitCleanup: quick-entry-cleanup
2026-02-01 06:15:33 [info] Successfully run onQuitCleanup: feedback-window-cleanup
2026-02-01 06:15:33 [info] Successfully run onQuitCleanup: local-mcp-server-cleanup
2026-02-01 06:15:33 [info] Successfully run onQuitCleanup: session-health-tracking
2026-02-01 06:15:33 [info] Successfully run onQuitCleanup: prototype-cleanup
2026-02-01 06:15:33 [info] Successfully run onQuitCleanup: mcp-shutdown
2026-02-01 06:15:33 [info] Successfully run onQuitCleanup: remote-server-cleanup
2026-02-01 06:15:33 [info] Successully ran all onQuitCleanup handlers, marking readyForQuit
2026-02-01 06:15:33 [info] beforeQuit: handler fired, going down
2026-02-01 06:15:33 [info] beforeQuit: handler is ready for quit, so quitting
                                                                          ← willQuit never fires
2026-02-01 06:18:59 [info] Using native Quick Entry overlay               ← 3.5 min later, process still alive

Successful quit — Jan 31, 23:45:55 (same session, same machine)

Identical cleanup chain, but willQuit fires as expected:

2026-01-31 23:45:50 [info] Successully ran all onQuitCleanup handlers, marking readyForQuit
2026-01-31 23:45:50 [info] beforeQuit: handler fired, going down
2026-01-31 23:45:50 [info] beforeQuit: handler is ready for quit, so quitting
2026-01-31 23:45:55 [info] beforeQuit: handler fired, going down
2026-01-31 23:45:55 [info] beforeQuit: handler is ready for quit, so quitting
2026-01-31 23:45:55 [info] willQuit: handler fired, going down              ← fires correctly
2026-01-31 23:45:55 [info] willQuit: handler is ready for quit, so quitting

Quick Entry crash after failed quit (main.log 06:19:25 and 06:20:25)

Each Quick Entry submission hits the same error:

2026-02-01 06:19:25 [error] Sentry caught: {
  eventId: '2b94025e9d624bc4bfe38616fdd98823',
  type: 'TypeError',
  value: 'Object has been destroyed',
  stack: undefined
}
2026-02-01 06:19:25 [info] [QuickEntry] Creating new chat (no chatId provided)
2026-02-01 06:19:25 [info] [QuickEntry] Submitting new chat payload to loaded page
                                                                          ← no window to receive it

A third Object has been destroyed error at 06:20:47 includes a stack trace pointing into the app's bundled index.js via a MenuItem click handler.

Zombie state confirmed (system-info.txt at 06:21:51)

Total Windows: 0

WebContents 1:
  ID: 3
  Type: window
  URL: file:///...find-in-page.html
  Loading: false
WebContents 2:
  ID: 2
  Type: window
  URL: https://claude.ai/chat/55e6ee22-d946-4798-94ef-5c986f874782
  Loading: false

Pre-existing issue — mainWindow.js preload failure

Unrelated to the quit bug but present on every launch since at least Jan 18 (main-window.log):

2026-02-01 06:05:23 [error] Unable to load preload script: .../mainWindow.js
2026-02-01 06:05:23 [error] Error: reply was never sent
2026-02-01 06:05:23 [error] Preload script failed to execute: 'mainWindow.js' reply was never sent
2026-02-01 06:05:23 [error] Uncaught ReferenceError: process is not defined

This recurs on Jan 18, Jan 29, Jan 31, and Feb 1.

---

Hypothesis

The quit flow calls app.quit() after beforeQuit marks readyForQuit, but something is preventing Electron from actually dispatching the willQuit event on this particular run. Possible causes: a lingering event listener or native reference (possibly from the MCP connections or the Quick Entry native overlay) is keeping the event loop alive and preventing the quit from completing, or the second beforeQuit re-entry after cleanup is calling app.quit() in a way that doesn't re-trigger the quit sequence on this Electron version.

---

Full log bundle

The complete debug log zip (generated via Settings → Debug → Export Logs on Feb 1 at 06:21 PST) is available and can be attached on request.

Claude-logs-2026-02-01T14-21-51-772Z.zip

Claude-logs-2026-02-01T14-21-51-772Z.zip

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗