Antigravity window renders only body background — UI layers never composited (Windows 11, RTX 4070 Ti)

Google Antigravity
1

Antigravity window renders only body background — UI layers never composited (Windows 11, RTX 4070 Ti)

Summary

Antigravity (both 2.0.1 and 2.0.6) launches successfully on my Windows 11 system, the language server starts and authenticates correctly, the renderer navigates to the IDE URL — but the window only ever shows the body background color. No UI layer is ever composited. The window is WS_EX_NOREDIRECTIONBITMAP (DirectComposition-only), which appears to be the key factor: PrintWindow capture of the client area returns a single uniform color (#202020 = the dark theme background) across the entire 1400×900 surface.

Other Electron / Chromium apps on the same machine (Claude Desktop, VS Code) work normally, so it’s specifically Antigravity’s render pipeline that fails here.

This was working on 2026-05-20 with 2.0.1. The last successful session was 2026-05-24 06:58. The next session 2026-05-24 12:50 already failed, and every launch since then has shown the same symptom. Nothing visible in Windows setup/event logs in that 6-hour window explains it.

Environment

  • OS: Windows 11 Pro 24H2 (Build 26200)
  • GPU: NVIDIA GeForce RTX 4070 Ti, driver 610.47 (clean install via DDU during troubleshooting)
  • Displays: MSI MAG 271QPX E2 (primary, 2560×1440 @ 240 Hz) + Gigabyte M27Q (secondary, 2560×1440 @ 59 Hz)
  • Antigravity versions reproduced on: 2.0.1 and 2.0.6 (both freshly installed from official installers)
  • Electron: 41.0.2 / Chromium 146.0.7680.72 / V8 14.6 (per /json/version endpoint)

Symptom in detail

After launching Antigravity (--in-process-gpu workaround required for 2.0.6, see below):

  1. Hub process and language_server process come up healthy
  2. [Auto-Restart] Port changed! Reloading all windows with URL: https://127.0.0.1:XXXXX/ is logged
  3. Language server log shows successful boot, auth, and ongoing loadCodeAssist / fetchAvailableModels API calls
  4. DevTools /json lists two pages:
    • The IDE page at https://127.0.0.1:XXXXX/ — title is empty
    • The splash data:text/html…Loading Antigravity… page
  5. The visible window:
    • Window chrome (title bar, buttons) renders correctly via DWM
    • Client area is uniformly #202020 (or #131313 if still on splash) — no loading dots, no text, no UI ever
  6. PrintWindow(hWnd, hdc, PW_RENDERFULLCONTENT) over the client area returns the same single color across all sampled pixels (12,600 samples, all identical)

Two distinct sub-symptoms on 2.0.6

A. GPU subprocess crashes at startup

ERROR:content\browser\gpu\gpu_process_host.cc:996] GPU process exited unexpectedly: exit_code=-2147483645
[repeated 6 times]
FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:417] GPU process isn't usable. Goodbye.

exit_code=-2147483645 = 0x80000003 = STATUS_BREAKPOINT at GPU process init.
Workaround: --in-process-gpu. With this flag, the hub no longer dies after spawn, but the compositing failure (B) appears instead.

B. Renderer composites only body background

With --in-process-gpu, the hub stays alive, the renderer process lives, but only the page background paints. Same on 2.0.1 (which doesn’t need the GPU workaround — its GPU subprocess starts fine).

What I ruled out

Hypothesis Result
Antigravity 2.0.6 specific bug ✗ 2.0.1 shows identical symptom
Corrupt userdata ✗ Rotated %APPDATA%\Antigravity and reinstalled, fresh profile
NVIDIA driver ✗ Same behavior on 32.0.15.9649 (May 2026) and freshly DDU-installed 610.47
MSI Afterburner / RivaTuner Statistics Server (RTSSHooks64.dll was in renderer) ✗ Closed via tray exit + per-app exclusion profile; symptom unchanged
Logitech G HUB ✗ Closed; symptom unchanged
Claude Desktop’s CoworkVMService ✗ Stopped; symptom unchanged
Any third-party DLL injection ✗ Renderer module list contains only Antigravity + Windows DLLs
HVCI / User-mode Code Integrity ✗ Not enforced (UserModeCodeIntegrityPolicyEnforcementStatus=0)
DWM cache corruption ✗ Killed dwm.exe, no change
Monitor refresh rate / G-SYNC ✗ Moved window to 59 Hz Gigabyte monitor, identical
GPU/shader cache ✗ Wiped GPUCache, DawnGraphiteCache, DawnWebGPUCache, ShaderCache, Code Cache, Cache
Site isolation / sub-renderer crashes ✗ --disable-features=site-per-process,IsolateOrigins,RendererCodeIntegrity no effect
ANGLE backend ✗ Tested --use-angle=swiftshader, --use-angle=gl, --use-angle=vulkan
DirectComposition disable ✗ --disable-direct-composition, --disable-gpu-compositing, --disable-features=VizDisplayCompositor

Chromium flag combinations tested (all show same compositing failure)

(none)
--in-process-gpu
--in-process-gpu --disable-gpu-compositing
--in-process-gpu --use-angle=swiftshader
--in-process-gpu --disable-direct-composition
--in-process-gpu --disable-direct-composition --disable-features=CalculateNativeWinOcclusion
--in-process-gpu --ignore-certificate-errors
--in-process-gpu --ignore-certificate-errors --use-angle=gl
--in-process-gpu --ignore-certificate-errors --disable-features=RendererCodeIntegrity
--in-process-gpu --ignore-certificate-errors --disable-features=site-per-process,IsolateOrigins,RendererCodeIntegrity
--in-process-gpu --ignore-certificate-errors --disable-features=VizDisplayCompositor,UseSkiaRenderer,Vulkan
--use-angle=vulkan --enable-features=Vulkan

Key window-style detail

Antigravity main BrowserWindow:
  HWND class:  Chrome_WidgetWin_1
  Style:       0x14C70000
  ExStyle:     0x00200100  →  WS_EX_NOREDIRECTIONBITMAP (0x00200000) is set

This means the window has no GDI redirection surface — the entire visible content depends on Chromium successfully presenting via DirectComposition. On this machine that presentation produces only the page background, never the React/UI layers above it. Standard Electron windows (which Claude Desktop uses) don’t set this style and render fine.

Suggested next steps for Google

  1. The combination WS_EX_NOREDIRECTIONBITMAP + this specific Windows/GPU/driver state seems to be the failure point. Is there a config or fallback that could disable transparent/no-redirection windows on Windows when DirectComposition presentation produces zero non-background layers?
  2. The STATUS_BREAKPOINT GPU subprocess crash in 2.0.6 (not in 2.0.1) is a separate regression worth investigating — what changed in the GPU sandbox setup between 2.0.1 and 2.0.6?
  3. A --disable-transparent-window or similar escape hatch would be enormously useful for diagnostics.

Diagnostic artifacts I can provide

  • Full main.log timeline showing exactly which sessions reached “Port changed!” banner vs. died at “Spawning…”
  • language_server.log showing healthy server-side after the auto-restart
  • Process module enumeration confirming no third-party DLLs in renderer
  • Get-CimInstance Win32_DeviceGuard output
  • Antigravity stderr capture with all GPU-process error lines
  • PrintWindow PNG showing the uniform #202020 capture

Happy to share any of these on request.

Reproduction: install Antigravity 2.0.1 or 2.0.6 on Windows 11 26200 with an NVIDIA RTX 40-series GPU. Launch with --in-process-gpu (required for 2.0.6, ignored by 2.0.1). Observe: window paints body background only, no UI ever appears.

1 Like