[BUG] App intermittently goes permanently blank/white during active session — no crash logged, no recovery
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The Claude Code desktop app (Windows, MSIX, v1.569.0, Electron 40.8.5) intermittently turns into a completely blank/white window during active work sessions. The entire UI disappears — just background color remains. The app never recovers; only a full restart fixes it. This happens multiple times per day.
Key observations:
Happens mid-session while Claude is working on tasks (user steps away for a minute, returns to white screen)
No renderer crash logged (Crashpad reports directory is empty)
No render-process-gone or unresponsive events in main.log
No OOM or memory errors
GPU never initializes properly: all GPUs show active: false, skiaBackendType: "None", glImplementationParts: "(gl=none,angle=none)" — but --disable-gpu (via ELECTRON_EXTRA_LAUNCH_ARGS) did not fix the issue
Windows Event Log shows ROOT\DISPLAY\0000 driver load failure (WUDFRd, 0xC0000365) around the same time, possibly related to display surface loss
Environment: Windows 11 Pro Build 26100.7309, NVIDIA GeForce RTX 3090 Ti (driver 32.0.15.9597, latest), 2560x1440 @ 150% scaling.
What Should Happen?
The app should never silently go blank without recovery — at minimum, detect the rendering failure and auto-refresh the webview
GPU initialization should not silently fail with all devices active: false on a high-end NVIDIA GPU
If the compositor/rendering surface is lost, the app should re-create it rather than staying permanently blank
Error Messages/Logs
No errors are logged at the time of the white screen. The failure is completely silent.
Potentially related findings from logs:
gpu-info.json (GPU never initializes):
{
"gpuDevice": [
{ "deviceString": "NVIDIA GeForce RTX 3090 Ti", "active": false },
{ "deviceString": "NVIDIA GeForce RTX 3090 Ti", "active": false },
{ "deviceString": "Microsoft Basic Render Driver", "active": false }
],
"auxAttributes": {
"skiaBackendType": "None",
"glImplementationParts": "(gl=none,angle=none)",
"inProcessGpu": true,
"supportsDx12": false,
"supportsVulkan": false,
"directComposition": false
}
}
Windows Event Log (around white screen occurrence):
Microsoft-Windows-Kernel-PnP Event 219:
Failed to load driver \Driver\WUDFRd for device ROOT\DISPLAY\0000 (Status: 0xC0000365)
sessions-bridge repeatedly dies (every ~4 hours):
[warn] Cap-redispatch budget exhausted for session; transport stays dead until app restart or system resumeSteps to Reproduce
Open Claude Code desktop on Windows 11 with NVIDIA GPU and 150% display scaling
Start a Claude Code session and give it a coding task to work on
Step away from the computer for 1-5 minutes (do not lock screen or put to sleep — just leave it idle)
Return to find the Claude Code window is completely blank/white
Try clicking, scrolling, Alt+Tab — nothing brings the UI back
Only force-quit and restart restores the app
Note: This is intermittent and not reproducible on demand. It happens multiple times per day during active use but the exact trigger is unknown. Network disconnection was ruled out as a cause (manually disconnecting VPN does not trigger the issue).
Claude Model
Not sure / Multiple models
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
Claude 1.569.0 (49894a) 2026-04-02T20:01:42.000Z
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
24 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
sorry, Same issue here https://github.com/anthropics/claude-code/issues/23637
Confirming a related but distinct manifestation on Windows 11 Pro x64, Desktop appVersion 1.1062.0 / CLI v2.1.92.
Instead of silent blank screen, I'm seeing full renderer crashes logged explicitly:
Main webview render process gone: { reason: 'crashed', exitCode: -1 }. 4 crashes in a single day (today, Apr 7 2026). One crash also took down the GPU process simultaneously:GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: -1, serviceName: 'GPU' }.Crash timeline from main.log:
Pattern: GPU crash at 15:56 appears to be the pivot point. After GPU dies, crash interval drops from ~3h15m to ~35-40 minutes. The GPU death destabilizes the rendering pipeline and crashes accelerate.
All 4 crashes reported to Sentry:
Crashpad/reports directory is empty — consistent with what you found. These renderer crashes don't generate minidumps.
Unlike your blank-screen case, my GPU does initialize (GPU crash is on exit, not init failure). But the core symptom — Electron's Chromium renderer failing on Windows without recovery — is the same. The crashes happen both during idle AND shortly after returning from idle, suggesting memory accumulation over time that triggers on render activity.
App auto-relaunches after each crash but sometimes requires Task Manager kill when relaunch fails to produce a usable window (tray zombie pattern).
Update: 2 more crashes since my last comment, now 6 renderer crashes in a single day on this machine.
New crashes:
Emerging pattern on the double GPU+renderer crashes:
Both of the worst crashes (15:56 and 20:16) — the ones where renderer and GPU die simultaneously and auto-relaunch fails — correlate with update check / GrowthBook refresh activity firing ~90 seconds before the crash. Log at 20:14:33:
[updater] Using GrowthBook check_interval_ticks=1 (default 4)thenChecking for updates, then crash at 20:16:05.The updater is running at 4x the default frequency. Update check → GrowthBook refresh → GPU/renderer destabilization seems to be a consistent precursor to the worst crashes.
Full crash timeline today:
12:41 renderer | 15:56 renderer+GPU | 16:36 renderer | 17:11 renderer | 20:16 renderer+GPU (Task Manager required) | 22:21 renderer
All renderer+GPU double crashes are the ones requiring Task Manager. Single renderer crashes auto-recover. This strongly implicates GPU process stability as the differentiator between recoverable and unrecoverable crashes.
ESCALATION — app is now in a crash death spiral.
7th crash at 22:41, only 7 minutes after the previous restart (22:34 restart → 22:41 crash). The crash interval has collapsed from ~3 hours this morning to under 10 minutes tonight.
Full day timeline — crash intervals shrinking:
The crash at 22:41 occurred only 7 minutes after a fresh startup — there's no time for memory to accumulate. Something in persistent state (IndexedDB, session storage, window-state.json) is corrupted and triggering the crash on every launch now. App is completely unusable.
Sentry ID for 22:41 crash:
f9b0f56ff9294dc58ce2290ae1fc5c2bThis is no longer an intermittent stability issue — it's a full session death spiral on Windows 11 x64, Desktop 1.1062.0. Needs urgent attention. 7 renderer crashes in one day, two of which took down the GPU process simultaneously and required Task Manager recovery.
Day 2 — crash continues. 8th renderer crash, first of the morning.
2026-04-08 09:02 PT. Desktop started at 07:48, ran 1h13m, renderer crashed. Renderer only this time (no GPU crash). Auto-recovered.
Sentry ID:
13194250663a41a0aa7ce64553dbcff6Running total: 8 renderer crashes in ~21 hours, 2 of which also killed the GPU process and required Task Manager kill. Desktop 1.1062.0 unchanged — no update has been pushed. This is not a transient issue. The renderer is crashing on a regular cadence (~every 1-3 hours) across two consecutive days with zero fix or acknowledgment.
At this point the pattern is clear enough to be a confirmed regression. Prior versions of Desktop did not crash this frequently. Something in 1.1062.0 has a renderer memory leak or instability that makes the Chromium process non-viable for sessions longer than ~1 hour.
Update: Desktop auto-updated to 1.1348.0 at 13:00 PT today (Apr 8).
10 renderer crashes total across Apr 7-8 on 1.1062.0 (7 yesterday, 3 this morning at 09:02, 10:16, 10:36). The 10:16 and 10:36 crashes were only 20 minutes apart — the death spiral from last night was continuing into today.
Desktop downloaded and installed 1.1348.0 at 13:00 via auto-updater, restarted cleanly at 13:07. No crashes since the update (monitoring). If the renderer instability was introduced in 1.1062.0 and fixed in 1.1348.0, this was a silent regression that caused 10 crashes in 22 hours with no user-facing acknowledgment.
Will report back if crashes resume on 1.1348.0.
NOT FIXED in 1.1348.0.
Crashed 9 minutes after the update installed. 13:07 startup → 13:16 crash. Same signature:
Main webview render process gone: { reason: 'crashed', exitCode: -1 }.Sentry ID:
a3fba7e4b0d042728413b431775d596dThis is crash #11 in ~25 hours. The update did nothing. Whatever is causing the Chromium renderer to crash on Windows is still fully present in 1.1348.0.
At this point this needs to be treated as a P0 regression. The renderer is crashing every 9-90 minutes across two consecutive Desktop versions on Windows 11 x64. 11 crashes in 25 hours. Anthropic has 11 Sentry event IDs from this machine. The fix is not in the update that just shipped.
I'm going to keep logging every crash. At minimum someone needs to look at the Sentry events and tell us what is actually crashing inside the renderer.
Crash #12. 5 minutes after crash #11.
13:16 crash → auto-recovered 13:17 → 13:21 crash. Same version (1.1348.0). Interval is collapsing again — same death spiral pattern as last night.
Sentry ID:
9b6ff06726a34b4582fa93bc78aac766Timeline on 1.1348.0 so far:
This is identical to the death spiral from Apr 7 22:34→22:41 (7 min interval). The renderer is crashing faster with each successive restart. This is not a memory leak with a long accumulation time — something is wrong on startup and each relaunch makes it worse.
12 crashes in 25 hours. Two Desktop versions. Zero fix. Zero response.
Anthropic engineering needs to look at the Sentry data. All 12 event IDs are in this thread.
4 more crashes on 1.1348.0. 16 total in ~30 hours. Nothing is fixed.
| Time (PT) | Sentry ID | Interval |
|-----------|-----------|----------|
| 13:46 |
43901dd7bbd049359289142dcac8bc5f| +25m after last crash || 13:51 |
a2e0e24e5cac4670ac67ce242de8002f| +3m (death spiral again) || 14:31 |
9cbf72bdb601470d8a87db7aecd2104e| +40m || 16:56 |
34c9129eee5746b490f9dc9f6e156185| +2h25m |All on Desktop 1.1348.0. Identical crash signature every time:
Main webview render process gone: { reason: 'crashed', exitCode: -1 }. No GPU crash on these four, just the renderer.Full crash record:
16 crashes. 2 Desktop versions. 3 days. Zero fix. Zero Anthropic response on this thread.
Anthropic engineering has 16 Sentry event IDs from one machine. The renderer is crashing every 3 minutes to 2.5 hours on a completely standard Windows 11 x64 setup. There is no workaround. The Desktop app is not usable for sustained work.
This needs a direct response from the Desktop team, not another silent update that changes nothing.
21 crashes in 3 days. Still zero response.
Tonight's crashes on Desktop 1.1348.0:
2b73e1b62bd34cf98cef9a3beecd11cc8562b4210cff4f458b335aa5a8b5a0e691bd533dabd04d6b8434d84fb4b5d846138c09ba63444b05b04752e02aaae13ace6467883e084eaf8393e70eba822cf2Full record:
21 total renderer crashes. 21 Sentry event IDs. 2 Desktop versions. 3 days. Zero acknowledgment. Zero fix.
This is not a niche hardware issue. This is a standard Windows 11 Pro x64 machine with an NVIDIA GPU. The Chromium renderer crashes every 15 minutes to 2 hours, consistently, across every Desktop version currently available.
I am a Max plan subscriber paying $200/month. I have provided more diagnostic data on this bug — timestamps, Sentry IDs, GPU correlation, interval patterns, log excerpts — than most Anthropic engineers would gather in a week of investigation. The least this deserves is a single sentence acknowledging it exists.
Is there a Desktop engineering contact? A separate bug tracker? Any channel where Windows renderer crashes are actually being looked at? Because this thread has been open for 2 days with 8 comments containing 21 crash reports and the silence from Anthropic is complete.
When I have it open, the rest of my desktop flickers (slightly reduced brightness which follows a predictable pattern)
Apr 11 update — 4 more crashes, 25+ total across 4 days. Still zero response.
Today's crashes on Desktop 1.1348.0 (Windows 11 Pro x64):
ce8ea7f991d1484cb29bd465053b172cba62d333d26b4dd5a819019c2004e701+e3f0b8a25b6942d9b33f85c1baae8fa2+5e3be06cecd745d696b28b987b38a72be154cbde8645496b880e8bf492724750+084bc71d292d471086ba48494825a8c5e988172dda3447d0ae07956c854ad46b+9b8ecbcb7f9b4b918691b8bc526b5815796195ba043a4d07a9527ed4235f4809+df892385892c4c7eb586ef6d796c5954The 19:01-19:11 pattern is the cascade: three renderer crashes in 10 minutes. Consistent with prior sessions where once GPU/renderer destabilizes, it crashes every 5 minutes until forced restart.
Running total: 25+ renderer crashes across 4 days (Apr 7-11). Desktop versions 1.1062.0 and 1.1348.0. Anthropic has 25+ Sentry event IDs from this single machine.
There is no version of Desktop that does not crash. The app is not usable for sustained work on Windows 11 Pro x64 with NVIDIA GPU. This is the fifth day of reporting with zero acknowledgment from the Desktop team.
Apr 12 update — identified likely trigger: GrowthBook account-change refresh + SkillsPlugin polling race condition.
Two consecutive days, crashes at exactly 13:51:06 PT. Log shows the crash fires at the same millisecond as:
The renderer dies the instant GrowthBook fires an account-change refresh while SkillsPlugin simultaneously polls. Apr 11 also shows
net::ERR_FAILEDon both GrowthBook and SkillsPlugin at crash time, suggesting a network event preceded or caused both.This is reproducible by timestamp: 13:51:06 two days running. Whatever triggers the GrowthBook account-change event at that time is the crash vector.
Apr 12 Sentry IDs (3 crashes today, gaps much larger than Apr 11):
1aba7c71b2da4d7aab4cf6af5afb3282f7df9385a833448a8ca61950c67c2b17+f19e5a3caba340d1a66aef3c2e089f22706f6290613a4bfd8cfc33816c2534d6+02d0a34bb803483aaf359f97ead30e33Running total: 28+ crashes across 5 days. The GrowthBook/SkillsPlugin pattern is present in at least the two 13:51 crashes. The Desktop team should be able to reproduce this by checking the GrowthBook refresh schedule against the Sentry event timestamps.
URGENT — Apr 12 afternoon: Active GrowthBook feature flag rollout is crash-looping Desktop on Windows.
The crash is now in a loop triggered by a live feature flag deployment. Pattern from today's log:
After every crash, GrowthBook reports 100 CHANGED features. Normal restarts show 0 changed. This means a feature flag rollout is actively pushing ~100 flag changes, the renderer loads them, and crashes ~5 minutes later. Then restarts, gets the same flags again, crashes again.
The log also shows being injected on every restart:
This is a computer use / automation feature block being enabled via feature flag. It's present on every post-crash restart.
This is not a flaky renderer issue. This is a feature flag rollout that is actively crashing Windows Desktop clients in a restart loop. If a GrowthBook flag deployment went out in the last few hours, rolling it back would stop the crash loop.
Apr 12 new Sentry IDs:
fe02390aa8fe404e95a4997a406f4638+9b52c56747424a83bcadf1e05acc969ced8e9001e17b4343858e1941d807fe23+e8fdc79778c14bcb8d14bd9733f2b4f38d43a78d99454d1dbf7960b5a6cc1b38+20c69fdeb8994abab9497f7ad04c0d9732+ crashes across 5 days. The Desktop team needs to check what feature flag deployment went out today and roll it back.
Apr 12 final count: 10 crashes in a single day. 46 total across 6 days.
Full Apr 12 crash timeline (Desktop 1.1348.0, Windows 11 Pro x64, NVIDIA GPU):
New Sentry IDs (post-14:16):
5fcc242fb26443e2b5d09437ff088f88+e91d60bf1d3f43b5bdd5e95cf3ef2955b6436815d8764eea84d1a6ba10356656+aa67c9437b0540e694f80c14d5d36baa30c3238bc9bd4ec79e7f40b37a8c9fe5+664dd4b05d294e3c91b517b3297ac044bbf7e71bb0c04f21bb3ef8f9d58fec68+a11940e249024d89a965bee16598269fRunning totals from log:
Anthropic has 46 Sentry event IDs from this one machine. The app is crashing roughly every 1-2 hours on average, with cascade periods every few hours where it crashes every 5 minutes. Both Desktop versions available (1.1062.0 and 1.1348.0) exhibit identical behavior.
At this point I would like to ask directly: is anyone from the Desktop team looking at these reports? 46 crashes, 6 days, zero response. I am a Max plan subscriber. This product is not functional on Windows.
Apr 12-13 update: 57 total crashes across 7 days. 17 on Apr 12 alone.
Apr 12 evening crashes (new since last report):
046360cc586b476cb254832a6f7c48c2+a54d6b6b7f334d24a31ebf5c3ebb3293bd98f1d87ad7451d8cd70a409713c2e5+adb37321478543f9a41554306ec4b9b347bcf135acf94987ba9c5434ad6233d0+56ed6986f3944e919a1f5fcdaacf7e09028ee1ce58d94c53a8de3a01bf05eae2+df06712971ae4347a035589c7ba13095e980a2e75e01489095c1aeb89be185c5+62208fa17877426581d8d24a795ef0e6+41b3e32e6958407bb81ffa802a8580e1+ca94cd11a4b74605917ae9e0e3396fd3Apr 13 crashes (overnight/this morning):
4509aa7af90c49de9b4f1da503ce723587046256d302491d8c0bfa98702edc72+7bee8859fb1b499cbfb75080f51b492c0f0b0ae5aad349128acb02f15070cc45+fc97f2198fa84dc58ffba390df5198a8e4ad549d1b77436f9cf88e61a6c17188+c210e37056ee4062b85032aad4401ef8Multiple cascades: 19:21/19:26 (5 min apart), 20:46/20:56 (10 min), 05:11/05:16 (5 min). The cascade pattern fires multiple times per day now.
Cumulative totals:
The crash rate is INCREASING. Apr 12 (17 crashes) is nearly double Apr 11 (10 crashes). This is not stabilizing.
I am asking for the last time through this issue: is there a Desktop engineer assigned to Windows renderer stability? If GitHub issues are not the right channel, tell me what is. I have provided more diagnostic data than any reasonable person should need to. At this point I would like either a fix, a workaround that actually works, or an acknowledgment that this is a known regression being actively investigated.
Apr 13 update: --disable-gpu did NOT fix the crashes. GrowthBook now pushing 102 changed features (up from 100 yesterday). 58 total crashes.
Crash at 08:31 PT —
e67f1b1d96ed47fca8c3aa5dcf1a5f0c+9f6e0739b3314df5adec81168a859e44After the crash, restart log shows:
Yesterday it was 100 changed. Today it is 102 changed. Anthropic pushed additional flag changes Monday morning. The
chicago_configcomputer use block (mouseAnimation, hideBeforeAction, autoTargetDisplay, clipboardPasteMultiline) is being loaded on every restart.--disable-gpuwas applied and did not prevent the crash. This rules out GPU hardware acceleration as the root cause. The crash is being triggered by the GrowthBook feature flag configuration — specifically the chicago_config computer use block being injected on Windows where it is apparently not safe.This is a server-side issue. Rolling back the chicago_config flag (or the broader 102-feature deployment) for Windows users would stop the crash loop. No client-side workaround will fix a server-pushed configuration that crashes the renderer.
58 crashes. 7 days. --disable-gpu confirmed ineffective. Root cause: GrowthBook flag deployment crashing Windows renderer on load.
Still crashing on Desktop 1.2278.0 — GPU + renderer double-crash confirmed.
Desktop updated to 1.2278.0 on Apr 13 at ~20:32. First crash on the new version:
02d2c5a6bd644087923fd180903ae8f3+605c284a0ed441daa355f09c74e2ca49+604e2abfe02f469ebc74f636d462ab11+eac8c95831a54a8486a0e857d3ed7c5e+e1a0ee2a224849eb8b176872501b847bCrash context from log:
Same pattern as before: crash fires on the update check tick, immediately followed by GrowthBook account-change refresh. Double GPU+renderer crash is the most severe failure mode we've seen — same as the Apr 11 cascade trigger.
GrowthBook is still loading 102 changed features on every cold start on 1.2278.0.
1.2278.0 did not fix this. The crash rate may be lower (app was closed overnight so only one crash to report), but the underlying crash mechanism is identical across 1.1062.0, 1.1348.0, and now 1.2278.0. Three Desktop versions, same crash, same GPU+renderer pattern, same GrowthBook trigger.
Running total: 59+ crashes across 3 Desktop versions and 8 days.
Apr 14 morning crash on Desktop 1.2278.0 — still happening.
830afb3324fd4b5480530a2c197847e4This is now confirmed across 3 Desktop versions (1.1062.0, 1.1348.0, 1.2278.0) and 8 days of continuous crashing. Every new Desktop release has been tested and failed to fix this.
60+ renderer crashes total. Same Windows 11 Pro x64 machine, same NVIDIA GPU, same GrowthBook trigger pattern.
At this point I would like to know if this issue is being actively investigated. A single sentence confirming someone has looked at the Sentry IDs would be sufficient. The silence across 8 days and 3 Desktop versions is not acceptable for a 00/month Max subscriber.
Apr 14 afternoon update — crashes continuing on Desktop 1.2581.0, plus new sync bug discovered.
Desktop auto-updated to 1.2278.0 → 1.2581.0 today. Crash-free since clean cache launch this morning (clearing GPUCache, DawnGraphiteCache, DawnWebGPUCache, Code Cache, Cache before relaunch). Cautiously optimistic on crash front.
New bug discovered (filed as #48125): Desktop conversation history never auto-loads. Every launch shows empty conversation list. Refresh button non-functional. Sign out → sign in required every session to see conversations. Log shows Electron blocking
background-syncpermission fromhttps://a.claude.ai/on every startup — this is the fetch path for conversation history.Cache clear workaround for crashes available at: the 5 renderer caches (NOT Session Storage — clearing that breaks conversation sync).
I'm experiencing the exact same issue, triggered when claude desktop loses focus, it has to be force closed through task manager and restarted
Experiencing the same blank/white screen issue, but in the Chrome extension version of Claude Code on Windows 11. Happens consistently after approximately 5 minutes of inactivity — the entire UI goes white and becomes completely unresponsive. Typing in the chat box does nothing. Only a full page refresh recovers it, losing any work in progress.
Root cause appears to be Chrome's MV3 service worker hard-termination after 5 minutes. The old Chrome flags to disable this were removed in v120+. A heartbeat/keepalive ping every ~4 minutes would likely fix it on the extension side.
This makes any long-running agentic task (document generation, browser automation, multi-step workflows) unreliable. Please reconsider the "not planned" close on #16350 — this is actively breaking real business workflows.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.