[Bug] Out of Memory errors causing frequent crashes

Renderer OOM-crashes (exitCode 5) within ~1–2 min when opening a Code session with an artifact pane open

Summary

The main webview renderer grows from ~0 to 4–5 GB RSS in 60–120 seconds after loading certain Claude Code (remote SSH) sessions that have an artifact open in the side pane, then crashes with reason: 'crashed', exitCode: 5. After a few crashes the app hits its reload cap and leaves the window blank. This happened 223 times between 2026-09-27 and 2026-10-07 (75 on Oct 6, 37 on Oct 7).

• Feedback ID: 8b43b5dc-8208-47aa-ad6e-03d3e201dcfc
• Sentry event (last crash): 0d8312b29a1e4dea984cf69d100f40ab

Environment

• Claude Desktop 2.26454.0 (Electron 44.4.3, Chrome 152.0.7977.130, Node 24.21.0)
• macOS 27.0 (build 26A434), Apple M4 Max, 128 GB RAM, arm64
• Sessions are Claude Code sessions over SSH to a remote host
• (Feedback was sent from Claude Code CLI 2.1.292 in Ghostty; the crash itself is in Desktop)

Steps to reproduce

1. Open a Code session that has an artifact open in the side pane, e.g. claude.ai/epitaxy/session_01D5vS3FFJPKJ5jdAKcQcawv?artifact=5a089bd6-8ca8-411a-98e5-6ae0d1d33494
2. Wait 1–2 minutes, or switch between this session and another one (session_01UotyCaL8qaoBU9iboUfguK)
3. The renderer crashes; the app reloads the same URL and crashes again until the reload cap is reached

Expected

The renderer stays within a reasonable memory budget, and a crash doesn't send the app back into the same failing URL.

Actual

Renderer memory from [process-memory] logging, one reload cycle:

12:39:46  electron_renderer  1193 MB
12:40:41  electron_renderer  3004 MB
12:41:39  electron_renderer  4552 MB
12:41:45  Main webview render process gone: { reason: 'crashed', exitCode: 5 }
12:41:46  Render process gone reload cap reached; not reloading again

Every crash in the logs follows the same pattern. With the webview gone, the rest of the process tree stays flat at ~1.4 GB (main process ~550 MB), so the growth is only in the renderer.

Correlation

URLs reloaded after crashes (all logs):

| Count | Session | Artifact |
|---|---|---|
| 23 | session_01D5vS3FFJPKJ5jdAKcQcawv | 5a089bd6-8ca8-411a-98e5-6ae0d1d33494 |
| 5 | session_01LKJF5BBufhTV1qZZ795Jq9 | 5a089bd6-8ca8-411a-98e5-6ae0d1d33494 |
| 5 | session_01D5vS3FFJPKJ5jdAKcQcawv | 5b5c368e-7eba-43d1-8b07-3dc358c060b2 |
| 2 | session_01UotyCaL8qaoBU9iboUfguK | afc21425-f044-40d7-8655-a2e4bdcdce13 |
| 1 | session_01UotyCaL8qaoBU9iboUfguK | 2a915438-1018-42c4-b0c2-0889a8c68b87 |
| 4 | various | none |

The same artifact (5a089bd6-…) shows up in two different sessions, which points to the artifact pane, or that artifact's content, as the likely cause. This is not confirmed: the logs show memory and URLs, not what is on the renderer heap.

Other notes

• MaxListenersExceededWarning (11 listeners on LocalSessions_onEvent, AppPreferences_preferencesChanged) appears on every renderer load. It's a small leak and probably not the cause, but worth a look.
• Full log bundle: Claude-logs-2026-10-07T10-53-03-236Z.zip (available on request; contains account details)

Suggested follow-ups

• Capture a renderer heap snapshot while loading the session above to find what is growing
• After an OOM crash, don't auto-reload into the same session/artifact URL

Possibly related

• #97044 — same renderer OOM (code 5) on macOS + Remote-SSH, but in the VS Code extension webview
• #81265 — Desktop webview OOM from unbounded memory growth (Windows, subagent fan-out)
• #97259 — Desktop window never recovers after the webview is killed