[BUG] Claude Desktop Electron main process grows unbounded (~3.7 GB/h) to 47 GB, triggering system-wide jetsam on macOS
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?
Related existing issues — I searched before filing, and this overlaps with open reports. Listing them up front rather than claiming novelty:
- #80056 (open) — closest match: memory leak in the Claude Desktop Electron main process, same OS build (macOS 26.5.2, Apple silicon). Reported there as 4.5–5.15 GB RSS over ~24 h on app version 1.22209.3, surfacing as a "Heavy memory usage" warning. My report is the same component two orders of magnitude worse on a newer app build (1.25927.0), ending in a kernel jetsam kill rather than a warning, plus a disk-write signal not mentioned there. Happy for this to be merged into #80056 if maintainers prefer.
- #18859 (open) — idle-session leak ending in jetsam, but that one is the
claudeCLI in a terminal, a different process. - #24583 (closed as not planned) — 36.5 GB single process, jetsam, hard reboot.
Summary
On a 16 GB MacBook Air (Mac16,13, macOS 26.5.2), the Claude Desktop main process (/Applications/Claude.app/Contents/MacOS/Claude) grew from 261 MB at launch to 47 GB over ~15 hours at a near-constant rate. At 06:07 the kernel fired a jetsam event with largestProcess: Claude and 335 MB of free pages, freezing the machine.
The growth is independent of activity
This is the key observation:
| time | footprint | note |
|---|---|---|
| 14:57 | 261 MB | app launched |
| 22:27 | 28.45 GB | +3.7 GB/h, sessions active |
| 23:26 | — | last session activity of the day |
| 06:07 | 47.3 GB | +2.2 GB/h with nothing running at all |
Between 23:26 and 06:07 no agent turn was in flight and no session transcript was written to disk, yet the process still added ~18 GB. So this is not context accumulation and not tool-output buffering — it grows while the app is completely idle. (#18859 reached the same conclusion independently for the CLI.)
Session transcripts on disk total only 78 MB across all projects, so the leak is not proportional to transcript size either.
Correlated disk-write storm
Apple's resource monitor flagged the same PID for dirtying 8.59 GB of file-backed memory over 27081 s — a sustained 317 KB/s against a 99 KB/s limit. The heaviest sampled stack in that report bottoms out in write() on the Node main thread.
Symbols resolve to nearest exports in the stripped Electron binary, so I cannot name the code path and will not guess at it. What is solid: the write loop and the heap growth are the same process over the same window. This may be the most tractable lead, since a write loop is easier to locate than a diffuse allocation leak.
Impact
Full machine freeze. At kill time the compressor had performed 4.65 billion compressions and the sum of all process footprints was 93 GiB on 16 GB of physical RAM. Not recoverable interactively — the machine had to be forced off.
What Should Happen?
The main process footprint should stay bounded, and in particular should not grow while the app is idle with no session in flight. After the last agent turn completes, memory should plateau.
An app left open overnight should not be able to reach 3x physical RAM and take the whole machine down with it.
Failing a fix for the leak itself, a ceiling or a watchdog that restarts or degrades the main process before it reaches jetsam territory would at least prevent the worst outcome — a full system freeze requiring a hard reboot.
Error Messages/Logs
JetsamEvent — 2026-08-07 06:07:04 +0500
os_version : macOS 26.5.2 (25F84)
product : Mac16,13 (16 GB RAM)
kernel : Darwin 25.5.0 / xnu-12377.121.10~1 RELEASE_ARM64_T8132
largestProcess: Claude
memoryStatus:
pageSize : 16384
compressions : 4,648,621,062
decompressions : 4,438,009,171
free pages : 21454 ( 335 MiB)
wired : 182386 ( 2850 MiB)
anonymous : 206351 ( 3224 MiB)
fileBacked : 131531 ( 2055 MiB)
sum of rpages over all 4000 processes: 93.29 GiB on a 16 GB machine
top processes by resident size (unrelated third-party app names redacted):
name pid RSS MiB peak MiB cpu s prio
Claude (Electron main) 64298 45074 45163 1620 100
kernel_task 0 3743 3858 80942 999
Claude Helper (Renderer) 64311 2694 2907 11397 180
fileproviderd 1203 2472 2487 24795 40
com.apple.WebKit.WebContent (x16) - 7484 - - -
com.apple.Virtualization.Virtual 72404 1964 1964 832 40
WindowServer 587 886 1662 143747 170
<other user applications> - ~8000 - - -
------------------------------------------------------------------------------
Microstackshots report, same PID 64298, window 2026-08-06 14:57 -> 22:27
Command: Claude
Path: /Applications/Claude.app/Contents/MacOS/Claude
Identifier: com.anthropic.claudefordesktop
Version: 1.25927.0 (1.25927.0)
PID: 64298
Num threads: 14
Event: disk writes
Writes: 8589.94 MB of file backed memory dirtied over 27081 seconds
(317.20 KB per second average), exceeding limit of 99.42 KB per second
Footprint: 261.47 MB -> 28.45 GB (+28.20 GB)
Pageins: 32858 pages
Start time: 2026-08-06 14:57:04
Heaviest stack (symbols are nearest-export matches in a stripped binary — approximate,
addresses given as Electron Framework offsets):
347 thread_start + 8 (libsystem_pthread.dylib)
347 _pthread_start + 136 (libsystem_pthread.dylib)
264 <Electron Framework + 20199460>
262 <Electron Framework + 27974628>
262 <Electron Framework + 27974844>
173 <Electron Framework + 27979324>
173 <Electron Framework + 4056324>
173 <Electron Framework + 4055980>
114 <Electron Framework + 37984660>
114 <Electron Framework + 30189820>
114 <Electron Framework + 75702172>
114 <Electron Framework + 75714700>
114 <Electron Framework + 31621668>
114 <Electron Framework + 31448404>
111 <Electron Framework + 31449644>
72 <Electron Framework + 31449904>
72 <Electron Framework + 38411624>
72 write + 8 (libsystem_kernel.dylib)Steps to Reproduce
I do not have a deterministic trigger — the leak is time-based rather than action-based. What I can characterise precisely:
- Launch Claude Desktop 1.25927.0 on macOS 26.5.2 (Apple silicon, 16 GB).
- Use Claude Code sessions in the app normally through the day. In my case roughly 8 sessions were opened over ~8 hours; one of them spawned 6 subagents. Nothing exotic — file edits, shell commands, an MCP server or two.
- Stop interacting with the app entirely, but leave it running.
- Sample the main process periodically:
``bash``
PID=$(ps -axo pid,comm | awk '$2=="/Applications/Claude.app/Contents/MacOS/Claude"{print $1;exit}')
while :; do /usr/bin/footprint -p "$PID" | grep phys_footprint; sleep 300; done
- Observed: the footprint climbs at ~2–4 GB/hour and never plateaus, including while fully idle. After ~15 hours it reached 47 GB and the kernel jetsammed it, freezing the machine.
Note on the rate. A freshly launched main process in the same setup grows ~4.7 MB/min (measured over 90 s while actively in use) — roughly 13x slower than the pathological rate above. So the process appears to fall into a fast-leak mode at some point rather than starting in it. I have not identified what flips it, and that is probably the most useful thing to chase.
Happy to run instrumentation, capture a heap snapshot of the main process, or test a build with symbols if that would help.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.221 (bundled in Claude Desktop 1.25927.0)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
Environment
- MacBook Air, Mac16,13, Apple silicon, 16 GB unified memory
- macOS 26.5.2 (25F84)
- Claude Desktop 1.25927.0, bundled claude-code 2.1.221
- Access via a Claude Pro/Max subscription, not an API key — the Platform dropdown has no option for that, so it is set to "Anthropic API" as the nearest match
- Not run from a terminal at all: this is the desktop app, hence "Other" for Terminal/Shell
- The leaking process is the Electron/Node main process — not the
claudeCLI, and not the renderer (the renderer peaked at 2.9 GB, unremarkable by comparison)
Two caveats on the preflight checklist, stated plainly
- "hasn't been reported yet" — partly it has. #80056 is open against the same component. I am filing separately because the magnitude, the jetsam outcome and the disk-write signal differ, but I am not claiming novelty and would rather this be merged into #80056 than tracked twice.
- "latest version" — the desktop app bundles claude-code 2.1.221 while npm latest is 2.1.223. I cannot pick the bundled version independently, and the leaking component is the Electron app itself (1.25927.0) rather than the bundled CLI.
Secondary observation
A com.apple.Virtualization.VirtualMachine instance in the same resource coalition (the sandbox VM) held 1.96 GB and dirtied 2.1 GB of file-backed writes over a comparable window. Much smaller than the main process and probably unrelated, but it starts within the same minute as the main process, so noting it in case the two are connected.
Available artefacts
I have the full JetsamEvent-*.ips (2.5 MB, 4000 processes) and the microstackshots .diag for the leaking PID. Both can be attached or sent on request.
The excerpt in the logs section above has process names of unrelated third-party applications redacted, along with local filesystem paths. The raw files contain the unredacted list — if you want them posted publicly, say so and I will attach them; otherwise I would rather send them through a private channel.
Current workaround
Restarting the app every few hours, plus a watchdog that notifies when the main process passes 8 GB RSS. Effective, but not something a user should have to run.