[BUG] Claude Desktop (Linux): main webview hangs with very long Code session; "kill and reload" leaves window frozen, no recovery screen

Status Open
Maintainer reply None cached
Activity 2 comments · opened Oct 3, 2026

Summary

On Linux, Claude Desktop's main webview hangs while a very long Code session is open. The app detects the hang and logs Main webview is unresponsive, will kill and reload, but the window never visibly recovers. It stays frozen: no error screen, no "Restart Claude" button (the v2.110.0 recovery UI never shows). This has happened 3 times in 8 days.

Environment

  • Claude Desktop 2.9939.4 (official .deb, amd64)
  • Ubuntu 24.04.5 LTS, kernel 6.8.0
  • GNOME on X11
  • NVIDIA GeForce RTX 3060, proprietary driver 580.178.04
  • 62 GB RAM

Occurrences (from ~/.config/Claude/logs/main*.log)

| Time (local) | Main renderer RSS just before | Notes |
|---|---|---|
| 2026-09-26 21:15 | ~690 MB | GPU process was killed twice and the network service restarted about an hour later (22:23), possibly unrelated |
| 2026-10-02 01:08 | ~830 MB | |
| 2026-10-03 12:09 | ~980 MB (peak 1,047 MB) | log line below |

2026-10-03 12:08:31 [info] [process-memory] ... top=[electron_renderer:<pid>:1047MB ...
2026-10-03 12:09:06 [info] Main webview is unresponsive, will kill and reload
2026-10-03 12:09:06 [info] [EventLogging] Flushing 16 events
... (only background session/auth housekeeping lines follow; the window stays frozen)

What the hang seems to correlate with

  • The session in focus at the 10-03 hang had a ~37 MB transcript (~3,100 JSONL entries, ~1,250 user/assistant messages, heavy subagent use). Other recent long sessions on this machine are 22–30 MB.
  • Not memory exhaustion: the renderer stayed under ~1.1 GB, total RAM is 62 GB, and there was no kernel OOM kill and no coredump at any of the three times.
  • Not the /dev/shm fd leak from #98725: the desktop processes hold 0 deleted /dev/shm fds after ~17 h of uptime.

So this looks like a main-thread hang (render or layout of a large transcript?), not a heap or OOM crash. On top of that, the kill-and-reload path does not leave a usable window on Linux.

Expected

  • A large session should not hang the main webview. The v1.37937.0 changelog says "Fixed very high memory use, and a blank or unresponsive window, when opening or reconnecting sessions with very large transcripts or many subagents", but this build is newer and still hangs.
  • If the webview is killed, the reload should succeed or the crash-recovery screen should appear, not leave a frozen window.

Related

  • #56379: large sessions crash the renderer (macOS, closed as stale/not planned)
  • aaddrick/claude-desktop-debian#664: same Main webview is unresponsive, will kill and reload on Ubuntu 24.04 when opening existing chats (closed)
  • #98725: Linux webview freeze from /dev/shm fd leak (ruled out here)

Workaround

Quit and relaunch the app. Avoid keeping very long sessions open in the desktop app (use the CLI instead).

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗