[Bug]: Agent UI (Electron) crashes in GPU-less environments (Windows Sandbox / VM) — child-process-gone type=GPU

[kovtcharov]

What happens: Agent UI desktop app crashes on launch in GPU-less environments. After the hub fix (#1698) it gets past catalog load, shows "Loading ML libraries" / "Loading catalog…", then the Electron GPU child process crashes and the whole app exits:

GAIA crashed
Error: child-process-gone: type=GPU reason=crashed
  at EventEmitter.<anonymous> (C:\Users\WDAGUtilityAccount\AppData\Local\Programs\gaia-desktop\resources\app...:11)
  at EventEmitter.emit (node:events:509:28)

Environment: Windows Sandbox (path shows WDAGUtilityAccount) — no GPU / hardware acceleration. Repro class: any GPU-less env (Windows Sandbox, bare VM, some RDP sessions). Electron ^42.2.0.

Root cause: src/gaia/apps/webui/main.cjs handles only Linux/Wayland GPU quirks and backend crashes — there's no app.disableHardwareAcceleration(), no GPU child-process-gone handler, and no software-render fallback. So a GPU-process crash on Windows is fatal.

Fix options:

1. app.disableHardwareAcceleration() before app.whenReady() — one line, robust everywhere, negligible perf cost for a chat UI. Recommended.
2. Handle GPU child-process-gone and relaunch with --disable-gpu — keeps GPU accel for normal users, more code.

Tests: manual repro in Windows Sandbox (no GPU) → app launches and renders. Reporter (@PCAssistSoftware) can retest on real hardware tomorrow to confirm it's GPU-specific.

Split from #1697 (the hub-unreachable error there is fixed in v0.21.2). Reported by @PCAssistSoftware.

[github-actions]

Confirmed — the root-cause analysis is accurate. src/gaia/apps/webui/main.cjs only guards Linux/Wayland GPU quirks (the WaylandColorManagement + ozone switches, lines 67–87) and watches the backend process; there's no app.disableHardwareAcceleration() and no GPU child-process-gone handler, so a GPU-process crash in a headless/GPU-less environment is fatal. 🟡

On the fix: I'd lean toward Option 2 rather than the blanket disableHardwareAcceleration(). Disabling accel unconditionally also slows the common case (real GPUs) for every user, to fix an environment most users never hit. A targeted child-process-gone/gpu-process-crashed handler that relaunches with --disable-gpu keeps accel for normal hardware and degrades gracefully only when the GPU process actually dies. If you want minimal code, a middle path is to detect GPU-less environments at startup (e.g. WDAGUtilityAccount / known sandbox markers) and disable accel just there — but the crash-handler approach is more robust since it covers bare VMs and RDP too.

Either way the switch must be applied before app.whenReady() (line 776), same as the existing Linux switches.

This is a good first-issue-sized fix if @PCAssistSoftware or another contributor wants to take it. The retest-on-real-hardware plan to confirm it's GPU-specific is the right call before merging. Thanks for the thorough writeup and the split from #1697.

[kovtcharov]

Superseded by #1799 — the bot already opened a fix PR for this exact crash. Closing as duplicate; tracking the fix there.

[github-actions]

Opened #1801 with a fix.

What was fixed: GAIA's child-process-gone safety net (main-safety-net.cjs) treated a GPU-process crash as fatal and exited the app. GPU crashes are recoverable — Chromium relaunches the GPU process and falls back to software rendering — so the handler now logs type=GPU crashes and lets Chromium recover; non-GPU child crashes stay fatal.

How to verify:

1. Check out the fix branch: git fetch origin autofix/issue-1800 && git checkout autofix/issue-1800
2. Build and launch the Agent UI in Windows Sandbox (no GPU)
3. Confirm the app gets past "Loading ML libraries" and renders the chat window — no "GAIA crashed — child-process-gone type=GPU" dialog
4. On a normal GPU machine, confirm it still launches/renders as before

The PR is a draft — the jest safety-net tests pass (GPU crash → no exit, non-GPU crash → still fatal) and there's no Python regression, but the real Electron GPU-crash repro needs manual validation on Windows Sandbox. @PCAssistSoftware, if you can retest on real hardware to confirm it's GPU-specific (as you offered), that'd help confirm the fix. A maintainer can validate and merge.