[BUG] Claude Desktop crashes under memory pressure during heavy Claude-in-Chrome browser automation (Windows)

Status Open
Maintainer reply None cached
Activity 1 comment · opened Aug 31, 2026

Description

Claude Desktop crashed on Windows 11 during a heavy browser-automation session (Claude in Chrome MCP tools driving many sequential computer/screenshot calls against Upwork). No graceful shutdown was logged. This has happened more than once under similar conditions.

Environment

  • OS: Windows 11 Pro 10.0.26200
  • Total system RAM: 15.3 GB
  • Free RAM at time of crash (from the app's own periodic memory log): declining steadily from ~2.8 GB to ~2.1 GB free over a few minutes, then the log stops mid-session
  • Claude Desktop's own process tree was using ~4.3 GB RSS in a separate, freshly-started instance shortly after (the electron_renderer process alone was ~1.8 GB), suggesting the app is a significant contributor to memory pressure on lower-RAM machines

What I found in the logs

%LOCALAPPDATA%\Claude\Logs\main1.log (the rolled-over previous-session log) ends abruptly at 2026-08-30 05:51:20 with no shutdown/exit log line — consistent with the process being killed (e.g. by the OS under memory pressure) rather than exiting cleanly.

In the ~2 minutes before the log cuts off, there are two warnings:

[warn] [claude-in-chrome] Tool call error: computer (24de56a6) after 30334ms
[warn] [claude-in-chrome] Tool call error: computer (756d8e23) after 30335ms

i.e. computer tool calls (screenshots) were timing out at ~30s right before the crash — this matches CDP Page.captureScreenshot timeouts I was independently seeing during a similar heavy-automation session.

%APPDATA%\Claude\Crashpad\reports is empty — no crash dump was captured, which points toward a hard OS-level kill (e.g. OOM) rather than an in-process exception Crashpad could catch.

Steps to reproduce (best guess)

  1. Run a long Claude Desktop session with Claude-in-Chrome doing sustained browser automation (many sequential screenshot/computer tool calls) against a real, complex webpage (in my case, Upwork search/job pages).
  2. Leave other memory-hungry apps running concurrently (Docker, IDE, multiple browser tabs).
  3. On a machine with ~15 GB total RAM, free memory drops toward ~2 GB.
  4. App becomes unresponsive to computer tool calls (30s timeouts) and is then killed/crashes with no graceful shutdown and no crash dump captured.

Expected behavior

Either the app should handle memory pressure more gracefully (release renderer memory, degrade instead of crashing), or at minimum a crash dump should be captured in Crashpad so the failure is diagnosable, and/or a clear warning should surface before tool calls start silently timing out and the app dies.

Additional notes

I wasn't able to determine the exact installed app version from the local install directory in this session, so I'm not including one — happy to provide it if pointed at where it's recorded on disk.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗