[BUG] Multiple Claude Desktop actions (deleting active chat, opening Preferences) freeze the entire macOS system

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?

Summary

Certain actions in the Claude desktop app cause total input lockup across the whole Mac — not just the Claude window. The clearest case is deleting a conversation from the sidebar while that conversation is currently open, which causes a freeze of roughly 1-2 minutes. A second, shorter version of the same freeze (10-20 seconds) happens when simply opening the app's Preferences window. This is not a spinning-beachball-on-one-window situation; system-wide input (Cmd+Tab, clicking the Dock, everything) stops responding entirely until the app recovers.

A Console.app Log Report captured a MaxListenersExceededWarning pointing at a leaking preferencesChanged IPC event listener (see "Error/Message Logs" below), and a macOS Diagnostic Report separately flagged Claude for sustained excessive disk writes — 2.1GB over ~37 minutes, ~39x over the OS's expected budget (see "Diagnostic Reports — Disk I/O" below). Together these look like strong candidates for the underlying cause and plausibly explain why the freeze affects the whole system rather than just the Claude window.

Environment

• Device: MacBook Pro 16,1 (2019)
• RAM: 16GB
• Storage: 1TB SSD
• OS: macOS 26.6.1 (Build 25G76) — "Tahoe"
• App: Claude desktop app (macOS), version 1.28929.0
• Architecture: x86_64 (Intel), Electron Framework 42.7.0

Steps to Reproduce

Case 1 — Delete active chat:

1. Open an existing (non-empty) chat from the sidebar so it's the active conversation.
2. While still viewing that chat, delete it from the sidebar (e.g., right-click → Delete, or the delete affordance on hover).
3. Observe the system freeze.

Case 2 — Open Preferences:

1. From anywhere in the app, open the Claude app's Preferences window.
2. Observe the system freeze.

Expected Behavior

Both actions should complete in a second or two, similar to deleting a chat while sitting in an empty New Chat window (see "Additional context" below), with no impact on the rest of the system.

Actual Behavior

• Case 1 (delete active chat): the entire system becomes unresponsive for approximately 1-2 minutes.
• Case 2 (open Preferences): the entire system becomes unresponsive for approximately 10-20 seconds.
• In both cases this is a full input lockup, not a per-window spinning beachball:
• Cmd+Tab does not switch apps.
• Clicking in the (auto-hidden) Dock does not reveal it.
• No other action of any kind is possible during the freeze.
• Control of the Mac returns once the app finishes whatever it's doing.

Diagnostic Data

Captured with iStat Menus during/immediately after a Preferences-window freeze:

• Memory Pressure: 32%
• Memory Used: 72% (App 6.4GB, Wired 3.0GB, Compressed 2.1GB, Free 4.5GB)
• Claude process memory: 2.7GB
• Swap Used: 0KB
• Page Ins / Page Outs: 1KB / 0KB

Notably, swap usage and paging activity are both effectively zero, which argues against memory pressure/swap-thrashing as the cause of the system-wide freeze (see revised theory below).

Top processes by memory at the same moment:

| Process | Memory |
|---|---|
| Claude | 2.7 GB |
| Dropbox | 690 MB |
| Finder | 592 MB |
| WindowServer | 514 MB |
| replayd | 510 MB |

Claude's memory footprint is roughly 4x the next-highest process (Dropbox) and larger than Finder and WindowServer combined. This points at Claude itself as the source of the resource pressure during these freezes, rather than an unrelated system process or another app.

CPU usage (via App Tamer, 5-second sample interval), captured during general idle/background use — not during one of the described freezes:

| Process | Current % CPU | % Avg CPU |
|---|---|---|
| Claude | 8.4 | 26.9 |
| replayd | 4.8 | 3.1 |
| Bartender 6 | 1.0 | 1.1 |
| ReportCrash | 0.0 | 1.0 |
| Magnet | 0.0 | 0.5 |
| iStat Menus Menubar | 2.0 | 0.4 |

Total CPU used by all apps at time of capture was only 7.9%, meaning Claude alone accounted for the large majority of active CPU use system-wide, with everything else in low single digits. The App Tamer CPU graph over time shows Claude periodically spiking to ~110% CPU (i.e., pulling more than a full core) at irregular intervals, rather than sitting at one sustained level — a recurring sawtooth pattern of spikes, not a one-time event tied to a specific click.

Error/Message Logs

Found via Console.app → Reports → Log Reports (Spin Reports were empty for these events). Latest entry, ~30 minutes after a Preferences-window freeze:

2026-08-13 11:36:26 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 $eipc_message$_71c3a57c-ba75-4667-8623-5ab5b17f38fb_$_claude.settings_$_AppPreferences_$_preferencesChanged listeners added. Use emitter.setMaxListeners() to increase limit

This looks like the likely root cause. It's Node/Electron's built-in EventEmitter leak detector reporting that a listener for an IPC event (claude.settings → AppPreferences → preferencesChanged) has been registered repeatedly without being cleaned up — 11 stacked listeners, past the default warning threshold of 10. This is consistent with a component (likely the Preferences window itself) subscribing to this event each time it's opened/triggered without unsubscribing, a classic listener-leak pattern.

This would explain several of the other symptoms in this report:

• Elevated baseline memory (2.7GB vs. ~600-700MB for comparable apps) — each leaked listener, and whatever it's closing over, is retained indefinitely.
• Periodic CPU spikes to ~110% even during idle use — if preferencesChanged (or a related sync/settings event) fires on any kind of interval or broadcast, every stacked listener runs on each firing, so the cost scales with how many times Preferences-related state has been touched during the session.
• The Preferences-window freeze specifically — opening Preferences is very plausibly what triggers registration of another listener on this channel, and/or triggers a preferencesChanged broadcast that now has to run through all the accumulated listeners synchronously.

Diagnostic Reports — Disk I/O

Found via Console.app → Reports → Diagnostic Reports, same general timeframe as the log warning above (a "Microstackshots" excessive-resource report generated automatically by macOS):

Event:            disk writes
Action taken:     none
Writes:           2147.49 MB of file backed memory dirtied over 2213 seconds (970.25 KB per second average), exceeding limit of 24.86 KB per second over 86400 seconds
Writes limit:     2147.48 MB
Writes duration:  2213s
Command:          Claude
Identifier:       com.anthropic.claudefordesktop
Version:          1.28929.0 (1.28929.0)

Heaviest stack for the target process:
  115  thread_start + 15 (libsystem_pthread.dylib + 6191)
  115  _pthread_start + 115 (libsystem_pthread.dylib + 23881)
  112  node::StreamBase::GetBytesRead(...) + 37531 (Electron Framework + 31951595)
  101    write + 10 (libsystem_kernel.dylib + 14722)
  11     writev + 10 (libsystem_kernel.dylib + 15314)

Footprint:        184.87 MB -> 256.58 MB (+71.71 MB) over the ~5.3 minute sample window

In plain terms: macOS's own diagnostics flagged Claude for writing 2.1GB to disk over ~37 minutes (970 KB/s average), roughly 39x over the sustained-write budget macOS expects (24.86 KB/s over 24 hours). The sampled stack shows a background thread spending 112 of 115 samples sitting inside a raw write()/writev() syscall — i.e., that thread is doing almost nothing but writing continuously. The memory footprint also grew +71.71MB in just the ~5-minute sampling window, consistent with the disproportionate overall memory usage noted above.

This is a plausible mechanism for why the freeze is system-wide rather than confined to the Claude window: sustained heavy disk writes can saturate the whole machine's I/O queue, stalling any process that needs to touch disk — which would include WindowServer/Dock, and would better explain total input lockup (no Cmd+Tab, no Dock) than a pure CPU-saturation theory alone. It's plausible the leaking preferencesChanged listeners (see above) and this sustained write activity are related — e.g., something being repeatedly serialized to disk on every fire of that leaking event — but that connection is speculative on my end and worth the app team's own investigation.

Additional Context

• If instead I'm sitting in an empty New Chat window (not viewing the chat being deleted) and delete a previous chat from the sidebar, the same kind of freeze occurs but is much shorter — only about 5-10 seconds.
• The difference in duration (deleting the active/open chat vs. deleting a chat while parked in an empty new chat) suggests the extra time is tied to whatever work happens when tearing down/navigating away from the chat that's currently being viewed, on top of the deletion itself.
• The fact that this now reproduces on a second, unrelated action (opening Preferences) suggests the root cause is something general in the app's main process (or its Electron/Chromium shell) rather than something specific to chat deletion logic — possibly a synchronous main-thread operation that blocks the process long enough to also stall the system compositor/WindowServer.
• The iStat Menus data above argues against my earlier swap-thrashing theory (swap is 0KB, paging is negligible). The macOS Diagnostic Report on sustained disk writes (see above) now looks like the more likely mechanism for the system-wide nature of the freeze, rather than memory pressure.
• Claude's own memory usage (2.7GB) is disproportionately high compared to every other running process at the time of capture, including Dropbox, Finder, and WindowServer combined. Even without a confirmed swap issue, this level of footprint for a chat app seems worth investigating on its own — possibly retained chat history/DOM nodes not being released, or memory not being freed after actions like the sidebar delete.
• The App Tamer CPU data strengthens the CPU-saturation theory: Claude's 26.9% average CPU usage is roughly 9x the next-highest app (replayd at 3.1%), and it periodically spikes to ~110% CPU even during otherwise idle/background use — i.e., not only during the delete/Preferences actions I originally reported. This points to a recurring background task in the app (polling, sync check, telemetry, or similar) that periodically pegs a full CPU core on its own, which may be compounding with (or possibly independently causing) the full-system freezes when it coincides with a heavier UI action.
• Would be happy to grab Activity Monitor CPU history / Console.app logs from the moment of a freeze if that would help narrow down the cause — let me know what's most useful to capture.

Impact

Severity feels high for how disruptive it is — losing full control of the machine for up to two minutes on a routine action (deleting a chat), and now also on simply opening Preferences, is a significant and recurring workflow interruption.

What Should Happen?

Both actions should complete in a second or two, similar to deleting a chat while sitting in an empty New Chat window, with no impact on the rest of the system.

Error Messages/Logs

2026-08-13 11:36:26 [warn] MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 $eipc_message$_71c3a57c-ba75-4667-8623-5ab5b17f38fb_$_claude.settings_$_AppPreferences_$_preferencesChanged listeners added. Use emitter.setMaxListeners() to increase limit

Event:            disk writes
Action taken:     none
Writes:           2147.49 MB of file backed memory dirtied over 2213 seconds (970.25 KB per second average), exceeding limit of 24.86 KB per second over 86400 seconds
Writes limit:     2147.48 MB
Writes duration:  2213s
Command:          Claude
Identifier:       com.anthropic.claudefordesktop
Version:          1.28929.0 (1.28929.0)

Heaviest stack for the target process:
  115  thread_start + 15 (libsystem_pthread.dylib + 6191)
  115  _pthread_start + 115 (libsystem_pthread.dylib + 23881)
  112  node::StreamBase::GetBytesRead(...) + 37531 (Electron Framework + 31951595)
  101    write + 10 (libsystem_kernel.dylib + 14722)
  11     writev + 10 (libsystem_kernel.dylib + 15314)

Footprint:        184.87 MB -> 256.58 MB (+71.71 MB) over the ~5.3 minute sample window

Steps to Reproduce

1. Open an existing (non-empty) chat from the sidebar so it's the active conversation.
2. While still viewing that chat, delete it from the sidebar (right-click → Delete, or the delete affordance on hover).
3. Observe: the entire system becomes unresponsive (no Cmd+Tab, no Dock, no input of any kind) for approximately 1-2 minutes before control returns.

Separately, a second freeze occurs via a different action:

1. From anywhere in the app, open the Claude app's Preferences window.
2. Observe: the same kind of full-system freeze occurs, lasting approximately 10-20 seconds.

Note: deleting a previous chat while sitting in an empty New Chat window (rather than the chat being deleted) also freezes the system, but only for about 5-10 seconds — included for comparison, not as a required repro step.

That covers the "clear, numbered steps" part. As for "include any necessary code, file contents, or context" — there's no user-written code or config file involved here, since this is a UI-triggered app bug, not something reproducible from a code snippet. I'd just note that plainly in the field (e.g. "N/A — this is a UI-level bug in the shipped app, not reproducible from a code sample") so the field isn't left looking incomplete or ignored.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.28929.0 (d1a6bc) 2026-08-11T18:58:06.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

<img width="322" height="679" alt="Image" src="https://github.com/user-attachments/assets/da8d96f6-4272-47bb-a6a4-982c8b74e9c5" />
<img width="260" height="444" alt="Image" src="https://github.com/user-attachments/assets/4860e05b-ebff-4a9a-8b57-e48c428ffdc4" />