Agent execution terminated due to error on headless Ubuntu VM (Gemini Models)

Google Antigravity
,
1

Environment Details:

  • OS: Ubuntu 24.04 LTS (Linode VM)

  • CLI Version: Antigravity CLI 1.1.22

  • Account Tier: Google AI Pro (Authenticated via OAuth)

  • Model: Gemini 3.1 Pro (High)

Issue Description: For the past two weeks, the Antigravity CLI operated flawlessly on my Ubuntu VM. Two days ago, it began immediately crashing whenever I attempt to use Gemini models. The UI simply outputs a generic warning, always terminating at execution step -2 (e.g., Error ID: 11ae6450-a645-46c5-a02a-7acb1dc78a67-2 or dfbcaeec-f7a6-4f48-b411-a560e0a0e160-2).

Using Claude models on the exact same VM works perfectly. Furthermore, using the exact same Gemini model via the CLI on my local M2 Mac works perfectly.

Troubleshooting Steps Taken (All Failed to Resolve): To isolate the root cause, I performed the following diagnostic steps:

  • Network & IP Routing: To rule out datacenter IP blocking, I routed the VM’s egress traffic through a residential IP using a Tailscale exit node and disabled IPv6 on the host. The crash persisted.

  • Workspace Context & MCP: To rule out context window exhaustion from large project files, I disabled all MCP servers and executed a simple “Hello” prompt inside a completely empty directory. The agent still crashed at step -2.

  • Deep State Reset: Uninstalled the CLI and recursively purged all state, cache, and token directories (~/.config/Antigravity, ~/.local/share/antigravity, ~/.gemini/antigravity, etc.). Re-authenticating via OAuth successfully logged me in, but the prompt execution still crashed.

  • Hardware Compatibility: Checked /proc/cpuinfo to ensure the virtual CPU isn’t failing on cryptographic instruction sets. aes, avx, avx2, and fma flags are all present and supported.

  • Capacity: Verified there are no active capacity constraints on my Google account.

Given that networking, context bloat, local state, and hardware instructions have all been ruled out, and since Claude continues to function on this same machine, this appears to be a backend initialization failure specific to Gemini on headless Linux instances.

Are there any internal telemetry logs associated with those Error IDs that can pinpoint what is failing during initialization?