[BUG] macOS desktop app (Code tab) repeatedly blacks out during long sessions — "Main webview is unresponsive, will kill and reload"

Same here, on Apple Silicon and macOS 27. One difference from the original report: on my machine the kill-and-reload never recovers. The window stays blank (or frozen) until I quit the app. The Code sessions keep running in the background the whole time (visible via Remote Control).

Environment

• Claude for Mac 2.31226.0
• macOS 27.0.1 (26A434), MacBook Air M1, 8 GB RAM
• Mostly the Code tab, 2–4 local Code sessions in parallel, 4 local MCP servers

Frequency (~/Library/Logs/Claude/main.log and rotated logs)

• 18 × Main webview is unresponsive, will kill and reload between 2026-09-18 and 2026-10-09, 4 of them today
• First occurrence 3 days after upgrading to macOS 27.0 (2026-09-15). Before that, 0 occurrences in the older logs (back to 2026-08-20). The app updated several times in the same period, so I can't separate the OS from the app version.

What the log shows around each event

• Every event is followed by beforeQuit: handler fired within 3–90 s. That's me quitting manually after the window stayed blank. In none of the 18 cases did the reload bring the window back. Sometimes Cmd+Q needs several attempts (once six beforeQuit lines within 90 s, once a second quit 23 min after the first) before the app actually exits.
• 86 × [process-memory] trigger=stall today alone
• Main renderer RSS at 450–600 MB, total tree footprint 1.1–2.3 GB. System swap at ~2.6 GB in use.
• Right before one event, tree RSS dropped from 1372 MB to 172 MB within a minute while the footprint stayed at ~2 GB (renderer pages compressed or swapped out). The watchdog fired about 50 s later:

12:36:01 [process-memory] trigger=interval tree_rss_sum=1372MB tree_footprint_sum=2039MB ... electron_renderer:503MB
12:36:28 [keep-awake] code session hold released (idle, held 1232791ms)
12:36:58 [process-memory] trigger=interval tree_rss_sum=172MB tree_footprint_sum=2010MB ... electron_renderer:16MB
12:37:47 Main webview is unresponsive, will kill and reload

Hypothesis: Under memory pressure the renderer is stalled or swapped long enough for the watchdog to declare it unresponsive. The kill itself is fine; the reload path is what fails on macOS, since the window never comes back. #99544 (macOS 27.0.1, M1 Max, closed by the bot as off-topic), #97259 (Windows) and #99142 (Linux) describe the same "never recovers after kill and reload" behaviour.

Happy to provide full log excerpts if useful.

Same on macOS, and frequent. The watchdog's kill-and-reload doesn't bring the window back. It stays blank or frozen while Code sessions keep running in the background, so I can't see or steer them until I quit the app.

Environment

• Claude for Mac 2.31226.1 (bundled Claude Code 2.1.295)
• macOS 27.0.1, Apple M3 Pro, 36 GB RAM
• Code tab, long sessions with heavy tool use and screenshots

Frequency (~/Library/Logs/Claude/main.log + rotated logs): 20 × Main webview is unresponsive, will kill and reload since 2026-09-28. That includes 5 on 10-08, 5 on 10-09 and 3 on 10-10.

Latest incident (2026-10-11)

21:23:23 [info] Main webview is unresponsive, will kill and reload
21:26:24          new Claude main process started (I had to Cmd+Q and relaunch)
21:26:28 [info] mainView ... boot: done

Nothing between the kill and my manual quit shows the main view booting again. Memory wasn't exhausted: the renderer was at about 720 MB and the whole app tree was about 6 GB out of 36 GB.

Impact: quitting is the only way to recover, and it stops every running Code session. Remote Control works as a stopgap.

Expected: if the reload fails, the main view should retry, or show a recovery screen that doesn't need a full quit.

Related: #97259 (Windows), #99142 (Linux), #99544 (macOS, closed by the bot, not fixed).

Update: 7 more today (2026-10-12) and 26 in total since late September. It isn't only long sessions. At 16:21 today the watchdog fired with no large session open, no builds running and the renderer at about 850 MB, on a 36 GB machine. The app is also unresponsive for the first seconds after waking from sleep while the network reconnects (18:13–18:14), and I had to quit it again. Logs available privately on request.