Title: Renderer process repeatedly crashes with OOM (reason: 'oom') — frequency escalating over ~3 days
Environment:
- OS: Windows 11 Pro (10.0.26200)
- Install: MSIX / Windows Store package
- App versions observed with this issue: 1.46388.4, 1.49585.0, 1.52386.0, 1.52386.3 (persists across auto-updates)
Symptom:
The main webview renderer process crashes with an out-of-memory reason and restarts itself. From %LOCALAPPDATA%\Claude\logs\main.log:
Main webview render process gone: { reason: 'oom', exitCode: -536870904 }
Each crash is preceded by the renderer's own memory ballooning from ~2GB to 4-6GB within 1-2 minutes (visible in the periodic [process-memory] log lines), while total system memory is not under pressure (several GB free out of 32GB total).
Frequency (escalating):
- 2026-09-09: 6 crashes over ~40 minutes (roughly every 5-8 min)
- 2026-09-10: 30 crashes, including a burst of 26 crashes in 40 minutes (~one every 90 seconds, 12:09-12:49)
- 2026-09-11: recurred; the app became unresponsive enough that I had to fully uninstall/reinstall to recover. During that recovery I saw a Windows "the file is being used by another process" message — possibly a child process from an earlier crash still holding a file handle, unconfirmed.
- No occurrences at all earlier in the same log file (back to 2026-08-20) — looks like a regression starting ~2026-09-09.
Likely same class of bug as other Electron AI-coding-assistant tools:
Same exact exitCode: -536870904 / reason: oom signature is reported in other Electron apps, notably Cursor's forum reports of "repeated renderer OOM crashes during agent-loop workflows" and renderer memory "steadily growing during/after AI workflows" (https://forum.cursor.com/t/repeated-renderer-oom-crashes-during-agent-loop-workflows/156475), plus Signal Desktop (signalapp/Signal-Desktop#7189) and VS Code (microsoft/vscode#303526). This suggests the leak may be in how long agent/chat sessions accumulate memory in the renderer (transcript rendering, message history, etc.) rather than something Claude-specific — worth checking if long-running sessions correlate with the crashes on this end too.
Impact: During the worst bursts the app effectively reloads every ~90 seconds, making it unusable. Full recovery required uninstalling and reinstalling.
Happy to share more log detail if useful — trimmed identifiers/session data out of this report.
Title: Renderer process repeatedly crashes with OOM (reason: 'oom') — frequency escalating over ~3 days
Environment:
Symptom:
The main webview renderer process crashes with an out-of-memory reason and restarts itself. From %LOCALAPPDATA%\Claude\logs\main.log:
Main webview render process gone: { reason: 'oom', exitCode: -536870904 }
Each crash is preceded by the renderer's own memory ballooning from ~2GB to 4-6GB within 1-2 minutes (visible in the periodic [process-memory] log lines), while total system memory is not under pressure (several GB free out of 32GB total).
Frequency (escalating):
Likely same class of bug as other Electron AI-coding-assistant tools:
Same exact
exitCode: -536870904/reason: oomsignature is reported in other Electron apps, notably Cursor's forum reports of "repeated renderer OOM crashes during agent-loop workflows" and renderer memory "steadily growing during/after AI workflows" (https://forum.cursor.com/t/repeated-renderer-oom-crashes-during-agent-loop-workflows/156475), plus Signal Desktop (signalapp/Signal-Desktop#7189) and VS Code (microsoft/vscode#303526). This suggests the leak may be in how long agent/chat sessions accumulate memory in the renderer (transcript rendering, message history, etc.) rather than something Claude-specific — worth checking if long-running sessions correlate with the crashes on this end too.Impact: During the worst bursts the app effectively reloads every ~90 seconds, making it unusable. Full recovery required uninstalling and reinstalling.
Happy to share more log detail if useful — trimmed identifiers/session data out of this report.