Claude Desktop renderer leaks ~1.1 GB/min in a repeating sawtooth, tearing down all MCP server connections

Summary

On two separate days, a Claude Desktop renderer process entered a repeating
allocate-and-collapse cycle: memory climbs at a remarkably consistent
~1.1 GB/min from ~1.3 GB to a ceiling of 8.5–10.8 GB, collapses back, and
starts again. The cycle ran for ~2h20m in the worst instance.

The practical impact is that every MCP server connection drops at once, because
the renderer is what relays MCP tool calls. From the user's side this looks like
"my MCP servers are randomly unreachable" — including the built-in Chrome
connector, which loses its native-messaging port at the same time.

Critically, no conversation was active during the worst of the leak, and the
same signature appeared on a different day in a different renderer PID with a
completely different set of tabs open. This looks app-level, not content-specific.

Environment

| | |
|---|---|
| Claude Desktop | 1.24012.11 |
| Electron | 42.7.0 |
| OS | macOS (Darwin 25.5.0), Apple Silicon Mac Studio, 64 GB |
| MCP servers configured | 16 stdio + 2 remote |

Evidence

All timestamps local. Source: ~/Library/Logs/Claude/main.log, which the app
helpfully instruments itself via [process-memory] lines.

Episode 1 — 2026-08-04, renderer PID 574

Ran 15:09 → 17:27. Four full cycles in the last 30 minutes alone:

17:00:00  renderer574=5974MB  avail=17108MB
17:01:03  renderer574=6614MB  avail=16219MB
17:01:59  renderer574=7378MB  avail=15390MB
17:02:57  renderer574=8018MB  avail=14863MB
17:04:02  renderer574=1295MB  avail=21615MB   <-- collapse
17:05:56  renderer574=2700MB  avail=19918MB
17:08:52  renderer574=5215MB  avail=17765MB
17:10:43  renderer574=6732MB  avail=15898MB
17:12:47  renderer574=8663MB  avail=14106MB
17:13:52  renderer574=1588MB  avail=21045MB   <-- collapse
17:15:48  renderer574=3571MB  avail=19102MB
17:18:43  renderer574=6920MB  avail=15420MB
17:19:46  renderer574=8080MB  avail=14285MB
17:20:42  renderer574=1889MB  avail=20255MB   <-- collapse
17:23:37  renderer574=5099MB  avail=17087MB
17:25:42  renderer574=7550MB  avail=14322MB
17:26:38  renderer574=8726MB  avail=12948MB
17:27:40  renderer574=1606MB  avail=22584MB   <-- collapse, cycle ends

Peak for the episode was 10,835 MB at 16:46:46. Count of samples above 6 GB,
by hour: 15:00 → 11, 16:00 → 16, 17:00 → 11.

Episode 2 — 2026-08-03, renderer PID 25133

Same signature, different renderer, different day:

17:34:06  renderer25133=1749MB
17:35:10  renderer25133=2882MB
17:36:06  renderer25133=3846MB
17:37:09  renderer25133=5030MB
17:38:10  renderer25133=6227MB
17:39:08  renderer25133=7247MB
17:40:12  renderer25133=8494MB   <-- peak
17:41:13  renderer25133=4784MB
17:42:12  renderer25133=1741MB   <-- collapse
17:43:14  renderer25133= 943MB
17:47:27  renderer25133=1973MB   <-- climbing again
17:48:30  renderer25133=2995MB
17:49:35  renderer25133=3900MB

Same ~1.1 GB/min slope, same ~8.5 GB ceiling.

Consequence: all MCP transports drop simultaneously

At 17:37:38 on 2026-08-04 the app's own stall detector fired
([process-memory] trigger=stall). Three seconds earlier, in
~/Library/Logs/Claude/mcp.log, all 16 MCP servers dropped in the same
millisecond window:

2026-08-04T21:37:35.957Z [info] [<server-1>]  Client transport closed
2026-08-04T21:37:35.958Z [info] [<server-1>]  Server transport closed (renderer released port)
2026-08-04T21:37:35.958Z [info] [<server-2>]  Client transport closed
2026-08-04T21:37:35.958Z [info] [<server-2>]  Server transport closed (renderer released port)
...  (16 servers total, all within 26ms)
2026-08-04T21:37:54.018Z [info] [<server-1>]  Initializing server...

They re-initialised 18 seconds later. Separately, the bundled Chrome connector's
native-messaging host lost its port three times in the same window
(~/Library/Logs/Claude/chrome-native-host.log):

[2026-08-04 17:27:13 INFO chrome-native-host] Chrome disconnected (EOF received)
[2026-08-04 17:33:12 INFO chrome-native-host] Chrome disconnected (EOF received)
[2026-08-04 17:37:53 INFO chrome-native-host] Chrome disconnected (EOF received)

That totalled ~27 minutes of Chrome-connector downtime in one hour.

Tool calls were silently lost, not just delayed. One of the affected MCP
servers is backed by a local HTTP service that logs every request on arrival. Over
the 95-minute window it received 299 health-check polls from its own watchdog but
only 6 real requests — the user's tool calls died in the renderer relay and never
reached the server. The server itself was healthy throughout (sub-300 ms health
responses, zero restarts in 2 days), so from the server side the outage was
invisible.

Ruled out

• Not CPU contention — 71.5% idle, load average 6.37 on 24 cores.
• Not system memory exhaustion — available memory never fell below 12.9 GB

of 64 GB during the cycle. (Note for triage: sys_free_raw in these log lines
drops to 60–90 MB, but that is normal macOS behavior and is not a pressure signal.)

• Not a crash — no .ips reports for Claude or Chrome in

~/Library/Logs/DiagnosticReports. The renderer is released, not killed.

• Not attributable to a conversation — during the leak's worst hour, no session

was processing anything; only idle-timeout housekeeping was logged.

• Not preview/webview tabs — this looked promising on 2026-08-04 (two preview

tabs open across the whole leak window) but is refuted by 2026-08-03, which shows
the identical sawtooth with zero PreviewContext open/close events all day.

Impact

MCP-heavy workflows become unreliable in a way that is very hard for a user to
diagnose, because the failure presents as "the MCP server is down" while the server
is provably healthy. In my case this cost several hours across multiple days chasing
server-side causes before the renderer was identified as the common component. There
is also no user-visible signal that MCP transports were dropped and re-established.

Suggested handling

1. Investigate the renderer allocation loop — the ~1.1 GB/min rate and ~8.5 GB

ceiling are consistent enough across days and PIDs to suggest a specific
allocation path rather than general churn.

1. Surface the trigger=stall / renderer-release event in the UI, so users know

their MCP connections were just recycled.

1. Consider making MCP transports survive (or transparently re-establish and retry)

a renderer release, rather than dropping in-flight tool calls silently.

Repro

No deterministic repro. Observed twice in two days on the same machine under normal
use with many MCP servers configured. [process-memory] lines in main.log make it
detectable: watch for a renderer growing ~1 GB/min.