Bug Report: Dual Language Server Instances Cause "Failed to fetch" on StreamAgentStateUpdates

Google Antigravity
, ,
1

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

  1. Launch Antigravity IDE.
  2. Observe that two language_server_windows_x64.exe processes spawn within ~7 seconds of each other (one from the main process, one from the Extension Host).
  3. Attempt to use IDE chat/agent features.
  4. 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.exe and Antigravity IDE processes 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.