[BUG] Gray Screen

[SoccerField24x7]

Problem (one or two sentences)

Occasionally/Randomly Roo gives the "gray screen of death".

Context (who is affected and when)

The issue seems to present most often on long running (multi-multi-turn) tasks.

MacOS 26.7
VS Code 1.136.1 (Universal)

Reproduction steps

As mentioned above, it's sporadic and I haven't identified the pattern.

It happens most often with long running / long elapsed time (sometimes I work over days) conversations.

Expected result

Error and recovery

Actual result

GSOD and you have to close VS Code and restart to clear the issue.

Variations tried (optional)

No response

App Version

3.82.1

API Provider (optional)

OpenAI Compatible

Model Used (optional)

gpt-5.6-sol (but it also happens on claude-opus-4.8)

Zoo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[myk1yt]

Triage notes (v3.82.2 codebase):

Already covered paths:

• The whole webview React tree is wrapped in an ErrorBoundary (webview-ui/src/App.tsx), so a JS render error already shows a recovery UI with the stack — a plain gray screen is therefore probably not a React render error.
• State pushes to the webview are throttled to prevent the OOM-driven gray screen (PR fix(webview): throttle state pushes to prevent gray screen OOM #1078, merged 2026-08-16). Since this report is from 3.82.1 (after that fix), the throttle mitigated but did not eliminate the problem.

Most likely remaining cause: webview renderer process crash under memory pressure on very long sessions (the webview accumulates the full multi-day conversation; the extension keeps posting full-state snapshots). The tracked work that addresses this class:

• feat(webview): incremental clineMessages delivery for focused task #630 — incremental clineMessages delivery for focused/long tasks
• perf: globalState write-through causes extension host freezes and OOM pause on large task histories #1541 / perf: remove globalState write-through for taskHistory #1542 — globalState write-through freezes / OOM on large task histories (implementation open as PR perf(webview): stop task history globalState writes #1664)
• [BUG] When using Claude and running two instances simultaneously, it consumes a massive amount of memory. It used up 20GB of my memory... #764 — memory blow-up with concurrent instances

If it recurs, the most useful artifacts for narrowing it down:

1. Help → Toggle Developer Tools → Console output around the failure (renderer errors appear there even when the boundary doesn't catch them).
2. macOS Activity Monitor sample of the Code Helper (Renderer) process for the window, so we can see whether it's steady memory growth vs. a spike.
3. Roughly how many messages / how much elapsed time, and whether the task had large file contents or images in context.

Happy to help dig further with that data.

[myk1yt]

Opened #1713 with a mitigation: heartbeat-based crash detection — the webview pings every 30s and the extension auto-reloads it when the renderer dies while visible, so the gray screen should recover by itself instead of needing a full VS Code restart. (The underlying long-session memory growth remains tracked in #630 / #1542.)

[filipworksdev]

Oddly enough the menu bar of the extension continues to work and if you open it in the editor it continues to work as normal. Edit: Also is not random it has to do with a session that is very long that overfills memory 3-4 gb limit aparently

[EpicLPer]

Opened #1713 with a mitigation: heartbeat-based crash detection — the webview pings every 30s and the extension auto-reloads it when the renderer dies while visible, so the gray screen should recover by itself instead of needing a full VS Code restart. (The underlying long-session memory growth remains tracked in #630 / #1542.)

I'm really looking forward to this being merged, it's been plaguing me like crazy these past weeks! I can roughly run tasks up to 30 minutes before it crashes or I close VS Code and then restart it.

Either way, a good step already! I think a different and maybe "future proof" approach would be for the extension to see how much memory it's using (if this is the crash reason) and if it approaches the limit within, say, 80%. If it does then schedule an automatic reload of the extension between API calls or commands so it doesn't break the flow or loses any context accidentally, then continues automatically in the previous conversation.