On startup, Antigravity IDE spawns two separate instances of language_server_windows_x64.exe — one from the Electron main process and a second from the Extension Host — each bound to different ports with different CSRF tokens. The UI/webview connects using the first instance’s port and token, but backend state updates register against the second instance. This causes a TLS handshake failure on the stale connection, which surfaces to the user as a persistent Failed to fetch error and blocks all agent/chat functionality.
Environment
- OS: Windows_NT x64 10.0.19045
- Antigravity IDE Version: 2.1.1
- VSCode OSS Version: 1.107.0 (user setup)
- Commit: e0b7a2bcf575cfba10528c4e7c10bd3ce2d7769a
- Build Date: 2026-06-17T22:39:43.962Z
- Electron: 39.2.3
- Chromium: 142.0.7444.175
- Node.js: 22.21.1
- V8: 14.2.231.21-electron.0
- Language Server CL: 9339240..
Steps to Reproduce
- Launch Antigravity IDE.
- Observe that two
language_server_windows_x64.exeprocesses spawn within ~7 seconds of each other (one from the main process, one from the Extension Host). - Attempt to use IDE chat/agent features.
- Chat/agent panel fails silently or shows
Failed to fetch.
Observed Behavior
1. Two concurrent language server processes
| PID | Start Time | Spawned By |
|---|---|---|
| 23636 | 12:41:05 PM | Electron Main process |
| 24740 | 12:41:12 PM | Extension Host process |
2. Mismatched ports and CSRF tokens
| PID | Ports (gRPC/HTTPS, HTTP, LSP) | Extension Server Port | CSRF Token |
|---|---|---|---|
| 23636 | 59204, 59205 | 59202 | 9b63fee3-… |
| 24740 | 59255, 59256, 59280 | 59252 | 00ada8c8-… |
The UI/webview initializes its connection against PID 23636 (port 59204/59205), but the Extension Host re-initializes LanguageServerClient against PID 24740 (port 59255/59256), leaving the UI’s connection pointed at a server that isn’t the one actually handling state.
3. Log evidence
ls-main.log — TLS handshake failures and aborted connections on the stale port:
2026/08/07 12:41:10 http: TLS handshake error from 127.0.0.1:59242: remote error: tls: unknown certificate
2026/08/07 12:41:10 http: TLS handshake error from 127.0.0.1:59239: remote error: tls: unknown certificate
2026/08/07 12:41:10 http: TLS handshake error from 127.0.0.1:59244: read tcp 127.0.0.1:59204->127.0.0.1:59244: wsarecv: An established connection was aborted by the software in your host machine.
2026/08/07 12:41:10 http: TLS handshake error from 127.0.0.1:59245: read tcp 127.0.0.1:59204->127.0.0.1:59245: wsarecv: An established connection was aborted by the software in your host machine.
Antigravity IDE.log — client used before proper initialization:
2026-08-07 12:41:10.590 [info] (Antigravity IDE) [ERROR]: Failed to show status message: LanguageServerClient must be initialized first!
renderer.log / ls-main.log — RPC/MCP concurrency conflict between the two instances:
[error] [unknown] loading already in progress: ConnectError: [unknown] loading already in progress
at Object.refreshMcpServers (...)
[error] [LS Main stderr] E0807 12:41:11.813228 23636 interceptor.go:74] /exa.language_server_pb.LanguageServerService/RefreshMcpServers (unknown): loading already in progress
4. Resulting user-facing error
Network tab in DevTools shows repeated failed requests:
StreamAgentStateUpdates — (failed) net::ERR_CONNECTION_...
Request URL: https://127.0.0.1:<stale_port>/exa.language_server_pb.LanguageServerService/StreamAgentStateUpdates
Expected Behavior
Only one language_server_windows_x64.exe instance should be spawned per Antigravity session, and the UI/webview should connect using the same port and CSRF token that the active backend instance is actually using.
Suggested Root Cause
A race condition between the Electron main process and the Extension Host: both processes appear to independently spawn a language server on startup rather than coordinating a single shared instance (or waiting for/reusing one already started). The Extension Host’s instance appears to “win” for handling actual state, while the UI remains wired to the main process’s now-orphaned instance.
Workarounds Found
- Fully killing all
language_server_windows_x64.exeandAntigravity IDEprocesses via Task Manager and relaunching sometimes resolves it, since the race condition doesn’t reproduce every launch. - Avoiding “Reload Window” mid-session (which restarts the Extension Host) appears to reduce recurrence.
Additional Notes
Happy to provide full log files or reproduce with additional diagnostics if useful.