What happened?
On 1.1.15 the main window went permanently blank white — no error page, no message, no way back. The app process stayed alive and responsive in the tray, my agent sessions kept running in the background, but the UI never came back. I eventually had to kill and relaunch the app.
The app's own log shows it made a deliberate choice not to recover. Three renderer crashes in the same run, all with the identical exit code — the app auto-reloaded after the first two, then gave up on the third:
17:30:05.799Z ERROR github_app: WebView2 process failure kind="render_process_exited" reason="crashed" exit_code=-1073741819 process="unknown" recovery=Reload
18:04:26.519Z ERROR github_app: WebView2 process failure kind="render_process_exited" reason="crashed" exit_code=-1073741819 process="unknown" recovery=Reload
18:09:47.495Z ERROR github_app: WebView2 process failure kind="render_process_exited" reason="crashed" exit_code=-1073741819 process="unknown" recovery=None
After the two recovery=Reload events the UI reattached within about a second. After recovery=None it never did, and the window stayed blank for 4 h 08 m until I force-quit. The host kept logging normally that entire time, so nothing was wedged — the app simply stopped trying.
This is a regression in handling, not a new crash. On 1.1.12–1.1.14 the same class of renderer death parked the window on the WebView2 "This page is having a problem" error page, which at least offered a refresh. 1.1.15 replaced that with silent auto-reload plus a terminal give-up state that renders nothing at all.
There is no in-app way out of the blank state: no error page, no context menu, no visible reload affordance, and the window has no content to accept a keyboard refresh.
Steps to reproduce
Not deterministic — it depends on hitting the underlying renderer crash (#3200) repeatedly in one run.
- Run 1.1.15 on Windows with several project sessions open and actively streaming output.
- Wait for the renderer to crash. The app auto-reloads and the UI returns after ~1 s.
- Let it crash again a short interval later (mine were 34 m apart, then 5 m apart).
- On the crash that follows closely after a previous reload, the app logs
recovery=None and the window goes blank white and stays that way indefinitely.
The recovery=Reload / recovery=None line in the app log is the reliable signal — it is emitted per crash and states the decision directly.
Expected behavior
A renderer crash should never leave the window blank with no route back. If declining to reload is intentional (a loop guard), the app should still present something actionable — the previous error page, a "Reload window" tray item, or an automatic retry on window focus.
Additional context
Environment
App version 1.1.15
OS Windows 10 Enterprise 25H2 (build 26200.9106)
Architecture AMD64
WebView2 runtime 152.0.4191.66
Copilot CLI 1.0.83-5
GPU 0 Intel(R) Graphics (32.0.101.8132)
GPU 1 NVIDIA GeForce RTX 5090 (32.0.16.1656)
WebView2 flags --disable-features=msWebOOUI,msPdfOOUI,msSmartScreenProtection,
CalculateNativeWinOcclusion,UiaProvider,AccessibilityBlockFlowIterator
--force-renderer-accessibility
Frequency
Three renderer crashes in the 62 minutes the UI was alive, one of which was terminal. The blank-window state has recurred across several 1.1.15 sessions today.
The WebView2 process failure log line appears in zero of my 20 retained app logs on 1.1.12, 1.1.13 and 1.1.14, and only in the 1.1.15 run — so both the auto-reload handler and the recovery=None state appear to be new in 1.1.15.
Extensions
Not tried with everything disabled — the crash is infrequent enough that a clean-profile run would take a long time to be conclusive. Worth noting that my canvas panels were unaffected and stayed rendered while the main window was dead, which is consistent with canvas panels running in separate WebView2 environments that do not carry --force-renderer-accessibility.
Related
Suggested labels: Bugs.
Diagnostics available on request
- Full app log for the affected run, including the three failure lines in context.
- WebView2
Breadcrumbs showing Tab1 RenderProcessGone with no following #reload for the terminal event.
In-depth investigation
The exit code changed between releases, which is why this looks like a new bug.
-1073741819 is 0xC0000005 (STATUS_ACCESS_VIOLATION). The earlier reports of this crash (#3135, #2861, #2989, #3019) were 0x80000003 (STATUS_BREAKPOINT) — a deliberate CHECK abort. Shipping AccessibilityBlockFlowIterator in --disable-features removes that CHECK but leaves the code path live, relocating the fault into an unguarded null dereference. Other reporters in #3200 symbolized the new form as blink::AXInlineTextBox::NeighboringOnLine, which #3200's body predicted as the sibling leaf. My WebView2 flags above confirm this build carries both AccessibilityBlockFlowIterator in --disable-features and --force-renderer-accessibility.
Correlating the recovery decision with the UI actually returning.
Each fresh renderer opens a new websocket connection to the host. Those connections line up exactly with the recovery decision:
| Crash |
Decision |
Next websocket connection |
| 17:30:05Z |
Reload |
17:30:06Z ✅ |
| 18:04:26Z |
Reload |
18:04:27Z ✅ |
| 18:09:47Z |
None |
never ❌ |
The host continued emitting normal log traffic (metrics batches, git trampoline activity) until I quit at 22:18Z, so the process was healthy throughout — this is purely the recovery decision, not a host hang.
It is a decision, not a failed attempt.
1.1.15 ships tracing metadata pointing at src-tauri/src/lib.rs in the 698–765 range, alongside strings including report_webview2_process_failure, recover_webview2_browser_process_failure, Failed to reload main webview after WebView2 render process exit, and Cannot reload main webview after WebView2 process failure without a sender.
Neither of those two failure strings appears anywhere in my log. So the reload was not attempted and did not fail, and the sender was not missing — recovery=None was selected before any attempt. Given the gaps between my three crashes (34 m 21 s, then 5 m 21 s), a rate limit on reloads within a time window would fit the observed behaviour, though I can't distinguish that from a simple attempt cap without disassembly.
Suggested fix.
Whatever the guard is, recovery=None currently degrades to a blank window with no affordance, which is strictly worse for the user than the pre-1.1.15 error page. Either always attempt the reload, or make the give-up path render the WebView2 error page / offer an explicit reload entry point so recovery doesn't require Task Manager.
What happened?
On 1.1.15 the main window went permanently blank white — no error page, no message, no way back. The app process stayed alive and responsive in the tray, my agent sessions kept running in the background, but the UI never came back. I eventually had to kill and relaunch the app.
The app's own log shows it made a deliberate choice not to recover. Three renderer crashes in the same run, all with the identical exit code — the app auto-reloaded after the first two, then gave up on the third:
After the two
recovery=Reloadevents the UI reattached within about a second. Afterrecovery=Noneit never did, and the window stayed blank for 4 h 08 m until I force-quit. The host kept logging normally that entire time, so nothing was wedged — the app simply stopped trying.This is a regression in handling, not a new crash. On 1.1.12–1.1.14 the same class of renderer death parked the window on the WebView2 "This page is having a problem" error page, which at least offered a refresh. 1.1.15 replaced that with silent auto-reload plus a terminal give-up state that renders nothing at all.
There is no in-app way out of the blank state: no error page, no context menu, no visible reload affordance, and the window has no content to accept a keyboard refresh.
Steps to reproduce
Not deterministic — it depends on hitting the underlying renderer crash (#3200) repeatedly in one run.
recovery=Noneand the window goes blank white and stays that way indefinitely.The
recovery=Reload/recovery=Noneline in the app log is the reliable signal — it is emitted per crash and states the decision directly.Expected behavior
A renderer crash should never leave the window blank with no route back. If declining to reload is intentional (a loop guard), the app should still present something actionable — the previous error page, a "Reload window" tray item, or an automatic retry on window focus.
Additional context
Environment
Frequency
Three renderer crashes in the 62 minutes the UI was alive, one of which was terminal. The blank-window state has recurred across several 1.1.15 sessions today.
The
WebView2 process failurelog line appears in zero of my 20 retained app logs on 1.1.12, 1.1.13 and 1.1.14, and only in the 1.1.15 run — so both the auto-reload handler and therecovery=Nonestate appear to be new in 1.1.15.Extensions
Not tried with everything disabled — the crash is infrequent enough that a clean-profile run would take a long time to be conclusive. Worth noting that my canvas panels were unaffected and stayed rendered while the main window was dead, which is consistent with canvas panels running in separate WebView2 environments that do not carry
--force-renderer-accessibility.Related
STATUS_BREAKPOINTform of the same crash, before the exit code changed.Suggested labels:
Bugs.Diagnostics available on request
BreadcrumbsshowingTab1 RenderProcessGonewith no following#reloadfor the terminal event.In-depth investigation
The exit code changed between releases, which is why this looks like a new bug.
-1073741819is0xC0000005(STATUS_ACCESS_VIOLATION). The earlier reports of this crash (#3135, #2861, #2989, #3019) were0x80000003(STATUS_BREAKPOINT) — a deliberateCHECKabort. ShippingAccessibilityBlockFlowIteratorin--disable-featuresremoves thatCHECKbut leaves the code path live, relocating the fault into an unguarded null dereference. Other reporters in #3200 symbolized the new form asblink::AXInlineTextBox::NeighboringOnLine, which #3200's body predicted as the sibling leaf. My WebView2 flags above confirm this build carries bothAccessibilityBlockFlowIteratorin--disable-featuresand--force-renderer-accessibility.Correlating the recovery decision with the UI actually returning.
Each fresh renderer opens a new websocket connection to the host. Those connections line up exactly with the recovery decision:
ReloadReloadNoneThe host continued emitting normal log traffic (metrics batches, git trampoline activity) until I quit at 22:18Z, so the process was healthy throughout — this is purely the recovery decision, not a host hang.
It is a decision, not a failed attempt.
1.1.15 ships tracing metadata pointing at
src-tauri/src/lib.rsin the 698–765 range, alongside strings includingreport_webview2_process_failure,recover_webview2_browser_process_failure,Failed to reload main webview after WebView2 render process exit, andCannot reload main webview after WebView2 process failure without a sender.Neither of those two failure strings appears anywhere in my log. So the reload was not attempted and did not fail, and the sender was not missing —
recovery=Nonewas selected before any attempt. Given the gaps between my three crashes (34 m 21 s, then 5 m 21 s), a rate limit on reloads within a time window would fit the observed behaviour, though I can't distinguish that from a simple attempt cap without disassembly.Suggested fix.
Whatever the guard is,
recovery=Nonecurrently degrades to a blank window with no affordance, which is strictly worse for the user than the pre-1.1.15 error page. Either always attempt the reload, or make the give-up path render the WebView2 error page / offer an explicit reload entry point so recovery doesn't require Task Manager.