[BUG] Claude Code output invisible for up to 2+ minutes due to Electron renderer memory explosion (Windows Desktop)

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?

When Claude Code streams responses in the Desktop app, the renderer process repeatedly enters a memory explosion cycle that blocks all Claude Code output from displaying for 17 seconds to 2+ minutes. Claude Code continues working in the background (tool calls execute, API responses arrive), but the user sees a frozen/hung chat with no progress indicator.

The freeze follows a repeatable pattern: the renderer accumulates DOM nodes from streaming content, memory climbs linearly to ~900 MB, then explodes to 1,050-1,290 MB with CPU spiking 3-4x. This happened 4 times in 30 minutes during a single session.

What Should Happen?

Claude Code streaming output should render progressively without the renderer process exceeding reasonable memory bounds or freezing the UI.

Error Messages/Logs

No error messages — the app appears "responding" to Windows but the UI is completely frozen. I built an external PowerShell process monitor to capture diagnostics.

Renderer process (PID 34568) — 4 freeze events in 30 minutes:

Freeze 1: 20:16:38 → 20:18:54 (2 min 16 sec)

20:16:30  CPU_delta=2.0   Mem=837 MB   (normal)
20:16:38  CPU_delta=10.4  Mem=1,252 MB  ← SPIKE
20:16:46  CPU_delta=11.6  Mem=1,259 MB
  ... sustained at CPU 10-11, memory 1,270-1,292 MB for 2+ minutes ...
20:18:54  CPU_delta=10.5  Mem=981 MB   ← starts dropping
20:19:10  CPU_delta=1.1   Mem=820 MB   ← recovered

Freeze 2: 20:28:29 → 20:28:46 (~17 sec)

20:28:13  CPU_delta=1.6   Mem=619 MB
20:28:29  CPU_delta=6.8   Mem=998 MB   ← SPIKE
20:28:38  CPU_delta=6.0   Mem=1,041 MB
20:29:10  CPU_delta=0.3   Mem=599 MB   ← recovered

Freeze 3: 20:30:39 → 20:31:03 (~24 sec)

20:30:39  CPU_delta=9.6   Mem=1,085 MB  ← SPIKE
20:30:47  CPU_delta=10.9  Mem=1,097 MB
20:31:20  CPU_delta=4.0   Mem=631 MB   ← recovered

Freeze 4: 20:34:10 → 20:35:46 (~96 sec)

20:34:10  CPU_delta=6.4   Mem=690 MB   ← onset
20:34:19  CPU_delta=11.1  Mem=1,049 MB  ← SPIKE
  ... sustained CPU 9.7-10.3, memory 1,050-1,069 MB ...
20:35:46  CPU_delta=7.0   Mem=1,183 MB
20:36:02  CPU_delta=0.2   Mem=1,169 MB  ← recovered

Pre-spike build-up pattern (linear DOM accumulation before Freeze 1):

20:14:30  523 MB  (handles: 532)
20:14:39  565 MB  (handles: 540)
20:14:47  598 MB  (handles: 548)
20:14:54  643 MB  (handles: 556)
20:15:02  690 MB  (handles: 564)
20:15:10  733 MB  (handles: 572)
20:15:18  778 MB  (handles: 580)
20:15:26  821 MB  (handles: 587)
20:15:50  903 MB  (handles: 599)
20:15:58  940 MB  (handles: 605)
→ BOOM: 20:16:38  1,252 MB

Handle count climbing 532 → 605 with memory increasing ~40 MB/8 sec = DOM nodes accumulating from streaming content until a threshold triggers massive layout/GC.

System-wide impact during Freeze 4:

20:34:07  System RAM: 22,546/32,384 MB (69.6%)
20:34:24  System RAM: 28,328/32,384 MB (87.5%)  ← +5,380 MB in 17 sec

Claude Code backend processes stayed healthy throughout all freezes:

• Sonnet session (claude.exe): steady ~435-500 MB, CPU_delta ~0.1
• Opus session (claude.exe): steady ~390 MB, CPU_delta ~0.02
• No process flagged NOT-RESPONDING by Windows

Steps to Reproduce

1. Open Claude Desktop on Windows with 2 concurrent Claude Code sessions
2. Have conversations with streaming responses containing code blocks and tool results
3. Monitor renderer process — observe linear memory climb → explosion → freeze → recovery → repeat

Claude Model

Sonnet and Opus (both active, bug is model-independent — it's a rendering issue)

Is this a regression?

Unclear — only started monitoring recently

Claude Code Version

2.1.63

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Claude Desktop (MSIX package Claude_1.1.5368.0_x64__pzs8sxrjxfjjc)

Additional Information

Pattern summary:

1. Streaming content arrives → DOM nodes accumulate → renderer memory climbs linearly
2. Renderer hits ~900-950 MB → triggers massive layout/GC/re-render cycle
3. CPU spikes to 10-11x normal, memory explodes to 1,050-1,290 MB
4. Claude Code output completely invisible for 17 seconds to 2+ minutes
5. Eventually recovers → memory drops to 550-600 MB
6. Cycle repeats (4 times in 30 minutes)

Related issues:

• #31643 — same platform, constant 18s input lag (possibly same root cause, also labeled invalid)
• #26552 — React #185 infinite re-render loop in renderer
• #25286 — similar memory/CPU pattern in TUI renderer