Antigravity 2.0 CLI: MCP servers fail to initialize (context deadline exceeded)

Google Antigravity
,
1

Problem Description
When starting Antigravity 2.0, several MCP servers, such as SonarQube and Sequential Thinking, fail to initialize correctly.
The client then aborts the connection and returns the terminal error: Error: context deadline exceeded.
At the same time, lightweight or purely local MCP servers, such as context7, sometimes connect without issues.
Notably, the same failing MCP servers work correctly inside the Antigravity IDE.

Technical Root Cause Analysis
A likely root cause is that some MCP servers report themselves as ready before their background initialization has actually finished.
The SonarQube logs strongly suggest this behavior.

INFO SonarQube MCP Server Backend service initialized.
INFO SonarQube MCP Server - Status: Server ready - tools loading in background
INFO SonarQube MCP Server - Waiting for background initialization to complete before shutdown… : context deadline exceeded

These logs indicate that the server becomes nominally available but still blocks while completing background startup work.
During that phase, it may still be resolving analyzers, fetching configuration, or establishing a secure connection to SonarCloud.
If the client requests the initial tool list during this window, the server may not respond quickly enough.
As a result, the handshake or tool discovery phase times out.

A second contributing factor appears to be the strict timeout behavior in the Antigravity 2.0 CLI.
The CLI seems to enforce a short, hard-coded timeout, roughly in the 5 to 10 second range, for the initial handshake and tool discovery process.
That is often not enough for remote or heavy MCP servers on a cold start, especially when they need to verify tokens, fetch remote state, or complete additional setup.
Unlike the IDE, the new Antigravity 2.0 launches these MCP servers from scratch for the active session, which makes initialization delays much more visible and much more likely to hit the timeout limit.

Moreover, it takes a considerable amount of time to initiate MCPs. This is because you have to reload several times before you see any MCPs starting.

Why It Works in the Antigravity IDE
The Antigravity IDE appears to manage the MCP server lifecycle differently from the new one.
Most importantly, it seems to tolerate longer initialization times and avoids blocking its main execution path in the same way.
It may also keep MCP server processes alive in the background, so once a server has completed its startup sequence, later requests no longer need to repeat the full handshake.
That would explain why the same servers work reliably in the IDE but fail in the CLI.

Proposed Solutions and Workarounds
One improvement would be to make the MCP handshake timeout configurable, for example, through an option or environment variable such as ANTIGRAVITY_MCP_TIMEOUT_MS.
That would allow users to increase the timeout for slower or network-dependent servers.

Another improvement would be asynchronous or lazy tool discovery.
In that model, MCP servers could return immediately with an empty or partial tool list, then publish the full set of tools once background initialization is complete.
This would prevent long startup work from blocking the initial connection.

A third option would be a warm-start daemon for the tool.
If the Antigravity 2.0 could keep MCP server processes alive across commands, it would avoid repeated cold starts and significantly reduce timeout-related failures.

2

Further analysis is provided based on reproducing this issue in a Windows 11 environment.

The root cause appears to be a combination of factors that reinforce each other. The initial connection delay is triggered by a local SSL certificate revocation list block (Windows Schannel CRL check). The client stalls while Windows attempts to reach an external CRL endpoint, which reduces the initialization window.
However, the actual crash is caused by three separate parser/client-side issues in Antigravity 2.0.

  1. Non-JSON stdout intolerance: the client parser expects strictly JSON-formatted output from the MCP server’s stdout from the very first line; any diagnostic message, warning, or status string printed before the JSON handshake causes an immediate parse failure.

  2. Stderr is treated as fatal. Any output on stderr (e.g., TLS warnings or CRL check messages from the OS) is incorrectly evaluated as a fatal connection error, triggering an abort rather than being logged or ignored.

  3. Hardcoded, overly short timeouts: the CLI’s initialization timeout (roughly 5–10 seconds) is far too rigid and provides no grace period for cold starts, SSL negotiation delays, or heavier servers such as SonarQube. The IDE handles this gracefully by keeping processes alive in the background, but the 2.0 does not.

3

So, how to solve this problem? I’ve tried ANTIGRAVITY_MCP_TIMEOUT_MS, but it’s not working… We need an update for Antigravity that allows us to set up MCP_TIMEOUT from the CLI.

This is ridiculous; we need to move to agy from the Gemini CLI… The Gemini CLI was much better than this agy.

A lot of features are not working with agy.

@Lberondroth, can you help me, bro? As I understand it, you described the reason for the problem, but it’s not the solution… correct?

I used a .env file. I also used env ANTIGRAVITY_MCP_TIMEOUT_MS=99000 agy, but it’s not working.

on Windows.

4

I tried many times with this issue. It simply isn’t like Gemini CLI. Also, AGY works differently, and there’s no memory system. Another issue is that MCP is not working, which is why I’m moving now to AionUI.

I cannot establish a business using the Antigravity CLI (AGY). I will still use AGY, but not to run my AGI, because the environment is so aggressive.

maybe i will use it as side tool