## Environment - OS: Windows 11 - CPU: Intel Core i7-1165G7 (11th Gen “Tiger Lake”, 4C/8T, base 2.80GHz) — NOT a hybrid P-core/E-core design - Virtualization: Disabled in BIOS/Windows - Antivirus: Avast (also reproduced with real-time protection fully disabled) ## Error shown to user “Startup failed - Language server exited unexpectedly (code=2, signal=null)” ## Root cause (from language_server.exe --stamp and full run logs) fatal error: unknown caller pc Occurring during GC background mark worker stack-scan, while the main goroutine is executing: regexp.MustCompile → google3/third_party/golang/enry/data/data.init() (content.go:956) This is a Go runtime crash inside package-level init of the `enry` (language detection) library — it happens even on the trivial `language_server.exe --stamp` invocation, not just full IDE startup. 100% reproducible, every single launch, no exceptions. ## Version bisection (confirmed on this exact machine) - v2.0.11 (released 2026-06-05) — WORKS, no crash - v2.1.4 (released 2026-06-12) — WORKS, no crash - v2.4.2 (released 2026-07-27) — CRASHES every launch - v2.11.0 — CRASHES every launch - v2.12.2 (current latest) — CRASHES every launch (Did not have a chance to test v2.2.1/v2.3.0/v2.3.1 individually — the regression was introduced somewhere between v2.1.4 and v2.4.2.) Currently stuck running v2.1.4 as the newest usable build, with auto-update disabled to prevent the updater from silently breaking the install again. ## Workarounds attempted — NONE of these fixed the crash on v2.4.2+/v2.12.2 - Full clean uninstall + reinstall (multiple times, including deleting %APPDATA%\Antigravity, %LOCALAPPDATA%\Programs\antigravity, and ~/.gemini before reinstalling) - Fully disabling antivirus (Avast) real-time protection - Setting `GODEBUG=asyncpreemptoff=1` as a **System** environment variable (not just a session/user var) + full machine reboot - Windows Power Mode set to “Best performance” (to rule out CPU frequency-scaling timing interaction) - Disabling Control Flow Guard (CFG) via Windows Exploit Protection → Program settings for both `Antigravity.exe` and `resources\bin\language_server.exe` + reboot ## Separate bug also found and fixed (may be related / may have contributed to a corrupted install state) `%LOCALAPPDATA%\antigravity-updater` existed as a **0-byte file** instead of a directory (created the exact same day as my first crash, 2026-07-27), which made every subsequent auto-update silently fail with:
Error: ENOTDIR: not a directory, mkdir ‘C:\Users\AppData\Local\antigravity-updater’
This blocked ALL updates for over a month even though the updater correctly detected newer versions were available. Deleting the stray file fixed the updater itself, but did not fix the language server crash. ## Related existing reports (same crash signature, no resolution yet) - https://discuss.ai.google.dev/t/language-server-exited-unexpectedly-code-2-on-intel-i7-7700-kaby-lake-after-latest-update-windows-11/146759 (older Kaby Lake CPU) - Bug Report for V2.0 (Intel Core Ultra 7 265 “Arrow Lake”, hybrid P/E-core) Note my CPU (Tiger Lake i7-1165G7) is NOT a hybrid P/E-core design, so this crash is not exclusive to hybrid CPUs as I initially suspected — it appears to be a broader Go runtime/compiler regression introduced in the language_server.exe build sometime between v2.1.4 and v2.4.2. ## Ask Given the crash is 100% reproducible on a completely clean install with a trivial `–stamp` invocation, this should be very easy to repro internally. Could someone from the Antigravity team take a look? Happy to provide the full main.log / language_server.log if useful.