Summary
The Antigravity provider on Windows never detects the Antigravity CLI (agy.exe), even when it is running and its local language server is listening. Upstream CodexBar supports an agy CLI source (and an OAuth remote fallback); neither appears to be ported — every --source value routes to the same local probe.
Environment
- Win-CodexBar 0.48.0, Windows 10 Pro 10.0.19045
- Antigravity CLI installed at
%LOCALAPPDATA%\agy\bin\agy.exe, signed in (Google AI Pro)
Repro
- Start an interactive
agy session. Confirm it is listening: Get-Process agy | % { Get-NetTCPConnection -State Listen -OwningProcess $_.Id } → two loopback ports.
codexbar-cli usage -p antigravity (any --source, ANTIGRAVITY_CLI_PATH set or not)- Result:
Provider not installed: Antigravity language server not running. Start Google Antigravity and sign in, then retry.
Root cause
rust/src/providers/antigravity/mod.rs — detect_process_info() only matches processes named *language_server_windows* / language_server.exe (the desktop IDE's child) and requires --csrf_token on the command line. agy.exe serves in-process with no such flag, so it can never match. --source cli/oauth still log Fetching Antigravity usage via local probe.
Evidence the data path works
With an agy session running, its quota endpoint answers without any CSRF token:
curl -sk -X POST https://127.0.0.1:<port>/exa.language_server_pb.LanguageServerService/RetrieveUserQuotaSummary -H "Content-Type: application/json" -d "{}"
returns the full quota summary (Gemini + Claude/GPT groups, weekly + 5h buckets). The existing listening_ports_for_pid() / find_api_port() plumbing would work as-is if discovery also matched agy.exe (with the empty-CSRF allowance upstream added for explicit CLI matches).
Ask
Port the upstream agy CLI source: match agy.exe in process discovery, allow empty CSRF for CLI matches, and ideally the launch-agy-on-poll behavior so quota renders when no session is open. Happy to test builds on a real Windows + agy setup.
Summary
The Antigravity provider on Windows never detects the Antigravity CLI (
agy.exe), even when it is running and its local language server is listening. Upstream CodexBar supports anagyCLI source (and an OAuth remote fallback); neither appears to be ported — every--sourcevalue routes to the same local probe.Environment
%LOCALAPPDATA%\agy\bin\agy.exe, signed in (Google AI Pro)Repro
agysession. Confirm it is listening:Get-Process agy | % { Get-NetTCPConnection -State Listen -OwningProcess $_.Id }→ two loopback ports.codexbar-cli usage -p antigravity(any--source,ANTIGRAVITY_CLI_PATHset or not)Provider not installed: Antigravity language server not running. Start Google Antigravity and sign in, then retry.Root cause
rust/src/providers/antigravity/mod.rs—detect_process_info()only matches processes named*language_server_windows*/language_server.exe(the desktop IDE's child) and requires--csrf_tokenon the command line.agy.exeserves in-process with no such flag, so it can never match.--source cli/oauthstill logFetching Antigravity usage via local probe.Evidence the data path works
With an
agysession running, its quota endpoint answers without any CSRF token:returns the full quota summary (Gemini + Claude/GPT groups, weekly + 5h buckets). The existing
listening_ports_for_pid()/find_api_port()plumbing would work as-is if discovery also matchedagy.exe(with the empty-CSRF allowance upstream added for explicit CLI matches).Ask
Port the upstream
agyCLI source: matchagy.exein process discovery, allow empty CSRF for CLI matches, and ideally the launch-agy-on-poll behavior so quota renders when no session is open. Happy to test builds on a real Windows + agy setup.