Renderer loads UI then crashes to blank window on hybrid GPU + Windows 26200 (2.1.4)

Google Antigravity
1

Antigravity 2.1.4 — renderer loads UI then crashes to blank window (backend healthy)

Summary

On a dual-GPU Windows machine, the Antigravity hub launches and the language server initializes completely successfully, the local HTTPS UI server is reachable and serves the UI bundle (HTTP 200), but the renderer window loads https://127.0.0.1:<port>/ and then goes blank — the page URL reverts to empty and the renderer becomes unresponsive. The window only ever paints the background color (#131313); the IDE UI never appears. This persists across full clean reinstalls.

Environment

  • Antigravity: 2.1.4 (same behavior on 2.0.11)
  • OS: Windows 11 Pro, build 26200 (Insider/preview channel)
  • GPU: hybrid — Intel UHD 730 (iGPU) + NVIDIA GeForce RTX 4060
  • Intel graphics driver: 32.0.101.7085 (latest)
  • Other Chromium/Electron apps (Chrome, VS Code) render correctly on this same machine.

What works (confirmed)

  • language_server.log: Auth succeeded, Serving UI bundle from embedded assets, initialized server successfully in ~2.4s. LS listens on the dynamic HTTPS port.
  • main.log: [Auto-Restart] Port changed! Reloading all windows with URL: https://127.0.0.1:<port>/
  • Direct GET https://127.0.0.1:<port>/ (cert bypass) returns HTTP 200 with a valid Antigravity HTML bundle containing window.__APP_CONFIG__.

What fails

  • The renderer window paints only the #131313 background; the React UI never renders.
  • Via Chrome DevTools Protocol, two page targets exist: the data: “Loading Antigravity” overlay and the main app page.
  • The main page briefly shows url = ``https://127.0.0.1``:<port>/, then reverts to an empty url (navigation does not hold).
  • Runtime.evaluate on both targets hangs / never returns → renderer main thread appears blocked/crashed. No JS console errors or exceptions are emitted.
  • History: the GPU process previously crashed repeatedly with STATUS_BREAKPOINT (exit_code = -2147483645), then FATAL: GPU process isn't usable. Goodbye.

Flags tested

  • --disable-gpu → app process exits immediately (~2s) at startup.
  • --disable-gpu-sandbox → app stays open but renderer still blank.
  • --no-proxy-server → navigation to the local HTTPS URL holds (without it the URL goes blank immediately). Root cause of the navigation problem: a residual WinINET system proxy entry pointing at a VPN endpoint (CyberGhost, 77.111.118.118:47286) — Chromium appears to route the localhost connection through it. With --no-proxy-server the page navigates, but the renderer still crashes to blank afterward.

Separate, minor bug also observed

app_storage.json written with a UTF-8 BOM makes the hub throw on every launch: Error reading storage items: SyntaxError: Unexpected token, ... is not valid JSON at StorageManager.getRawItems (dist/storage.js). The storage reader should tolerate a BOM.

Repro steps

  1. Launch Antigravity on the environment above.
  2. Wait up to 3 minutes.
  3. Window shows blank #131313; no IDE UI.
  4. Confirm LS is healthy via logs and GET https://127.0.0.1:<port>/ → 200.

Asks

  1. Fix the renderer crash / blank-page on hybrid-GPU + Windows 26200 (likely a GPU process / compositor crash in the bundled Electron/Chromium).
  2. Make the renderer ignore the system/VPN proxy for 127.0.0.1 loads.
  3. Make app_storage.json parsing BOM-tolerant.
2

Hi @meron,

We haven’t been able to reproduce this blank renderer behavior on our end just yet. To help us better assist you and investigate this further, could you try a few troubleshooting steps and share some additional details?

  • Please try forcing the Antigravity executable to specifically use either the “High Performance” (NVIDIA) or “Power Saving” (Intel) GPU via the native Windows Graphics settings menu to see if it bypasses the crash.
  • Since Build 26200 is an Insider Preview channel, could you check if this same unexpected behavior occurs on a stable Windows 11 release with a similar hybrid hardware setup?
  • Any additional verbose logs or crash dumps you can capture and share would be greatly appreciated as we continue to look into this.