Antigravity IDE 2.6.0: HTTP 400 Bad Request (INVALID_ARGUMENT) during agent trajectory execution

Google Antigravity
,
1

Summary

During multi-step agent execution in Antigravity IDE v2.6.0, the agent terminated abruptly with an unhandled HTTP 400 Bad Request (INVALID_ARGUMENT) error from the Cloud AI Companion backend API.

Error Details

  • Trajectory ID: fcda791e-f066-4eec-a454-49e4****
  • Trace ID: 0x62bab8eeb*****
  • Error Code: 400 Bad Request
  • Status: INVALID_ARGUMENT
  • Message: Request contains an invalid argument.

Sherlog Headers

{
  "Alt-Svc": ["h3=\":443\"; ma=2592000,h3-29=\":443\"; ma=2592000"],
  "Content-Length": ["127"],
  "Content-Type": ["text/event-stream"],
  "Date": ["Wed, 28 Oct 2026 23:12:19 GMT"],
  "Server": ["ESF"],
  "Server-Timing": ["gfet4t7; dur=7714"],
  "Vary": ["Origin","X-Origin","Referer"],
  "X-Cloudaicompanion-Trace-Id": ["62bab8eeb*****"],
  "X-Content-Type-Options": ["nosniff"],
  "X-Frame-Options": ["SAMEORIGIN"],
  "X-Xss-Protection": ["0"]
}

Environment Context

  • Antigravity IDE Version: 2.6.0
  • VSCode OSS Version: 1.107.0 (user setup)
  • Commit: 9e3a5da5d6731effd57d47d88bbe*****
  • Date: 2026-10-26T18:06:23.613Z
  • Electron: 39.2.3
  • Chromium: 142.0.7444.175
  • Node.js: 22.21.1
  • V8: 14.2.231.21-electron.0
  • OS: Windows_NT x64 10.0.26200
  • Language Server CL: 1007378935
  • Account Plan: Google AI Pro (Active quota: 45% weekly remaining, 97% 5-hour limit remaining)

Steps to Reproduce

  1. In Antigravity IDE, work on a project workspace located on WSL2 / remote filesystem (cadensa-web).
  2. Run an agent execution turn with multi-step reasoning/tool calling.
  3. Suddenly the execution aborts with red banner:
    • Error Agent execution terminated due to error.
    • Error ID: fcda791e-f066-4eec-a454-49e4d5e8f3e7-740
    • Error ID: fcda791e-f066-4eec-a454-49e4d5e8f3e7-741
  4. System warning surfaces: This conversation is in a different workspace. Missing Folder: cadensa-web does not exist. Agent terminated due to error.
2

@merolhack The HTTP 400 INVALID_ARGUMENT and subsequent Missing Folder: cadensa-web abort is caused by cross-boundary path serialisation between Windows Electron and the WSL2 filesystem.

Here is the exact failure mechanism and the two reliable architectural workarounds:

  1. Root Cause: Path Desynchronization Across Trajectory Turns
    In Antigravity IDE on Windows, when opening a project workspace located inside a WSL2 distribution (e.g. via \\wsl$\Ubuntu\... or \\wsl.localhost\...):
  • Initial workspace mounting succeeds locally, but as multi-step agent trajectories execute, file-modification tool calls pass POSIX paths (e.g. /home/user/cadensa-web/...) back to the language server daemon.
  • When the language server attempts to construct the next interaction turn payload to the Cloud AI Companion backend API, it normalises the workspace URI against the Windows UNC mount.
  • Antigravity’s path serializer URL-encodes backslashes into %5C, causing the backend companion service to fail path schema validation with HTTP 400 (INVALID_ARGUMENT: Request contains an invalid argument).
  • When the connection aborts, the IDE attempts to recover the session state, evaluates the encoded path, fails to resolve the local root, and throws Missing Folder: cadensa-web does not exist.
  1. Workaround A: Network Drive Letter Mapping (Fastest In-IDE Fix)
    Map the WSL2 network share to a standard Windows drive letter rather than opening the raw UNC path:
  2. In Windows PowerShell:
New-PSDrive -Name "W" -PSProvider "FileSystem" -Root "\\wsl.localhost\Ubuntu\home\<your_user>\projects" -Persist

(Or in Windows File Explorer: Map Network Drive → assign W: to \\wsl.localhost\Ubuntu\home\<user>\...)
2. In Antigravity IDE: File > Open Folder > Navigate to W:\cadensa-web.
Because the workspace path is now a deterministic DOS drive path (W:\cadensa-web), the language server serialises path arguments without UNC backslash %5C corruption, preventing the HTTP 400 schema error.

  1. Workaround B: Native Linux CLI + Remote Control (Optimal for Performance)
    For heavy multi-turn agent execution on WSL2, run the agent runtime natively inside the Linux subsystem rather than through the Windows Electron host bridge:
  2. Inside your WSL2 terminal:
agy --remote-control
  1. Open the printed session URL in your browser. Because the entire agent trajectory and file system calls execute natively under POSIX /home/..., there is zero Windows-to-WSL UNC path translation.
3

Hi @merolhack,

Thank you for reporting this and sharing the error details.

The HTTP 400 Bad Request (INVALID_ARGUMENT) error paired with This conversation is in a different workspace. Missing Folder: cadensa-web does not exist happens when the conversation history contains a malformed request or references a project folder that is no longer accessible from the current host environment. Once that failed step is saved in the conversation history, subsequent turns in the same thread will continue to return 400 INVALID_ARGUMENT.

Please try starting a new conversation (+ in the IDE, or /clear / /new in the CLI), closing any unused editor tabs, and checking that any custom MCP server tool definitions are valid (/mcp). In addition, per our Getting Started guide, Antigravity opens a local working directory on the host OS where the app is running. When working across Windows 11 and WSL2 (Ubuntu 20.04), we recommend either opening the project from a local Windows folder when using the Windows IDE, or running the native Linux build or Linux CLI (curl -fsSL https://antigravity.google/cli/install.sh | bash) directly inside Ubuntu 20.04 (you can also run agy --remote-control to use the browser UI at antigravity.google.com per the Remote Control guide).

If the issue persists in a new conversation when opening a local folder on the same OS, please reach out back to us.