feat(cli): add native Antigravity OAuth provider

[pmos69]

Summary

Closes #29294.

This PR adds a native google-antigravity provider for Hermes. It is an alternate implementation to #29385 with a different auth/model-discovery tradeoff: Hermes owns the Antigravity OAuth PKCE flow and stores its own tokens, while discovering the Antigravity desktop OAuth client credentials from the installed agy binary or explicit env overrides. The model picker uses live Antigravity model discovery with a curated fallback.

The provider is opt-in and keeps existing gemini and google-gemini-cli behavior unchanged.

Why this route

• Adds a separate google-antigravity provider and aliases (antigravity, antigravity-oauth, antigravity-cli, agy, agy-cli).
• Stores Antigravity OAuth credentials separately under ~/.hermes/auth/antigravity_oauth.json, so Hermes profiles do not share or mutate Antigravity CLI token state.
• Does not check in Antigravity OAuth client secrets. Hermes uses HERMES_ANTIGRAVITY_CLIENT_ID / HERMES_ANTIGRAVITY_CLIENT_SECRET when set, otherwise discovers the desktop OAuth client from installed agy / HERMES_ANTIGRAVITY_CLI_PATH / common install locations.
• Uses Antigravity Code Assist metadata/headers/endpoints directly rather than shelling out to agy for inference.
• Discovers account-entitled Antigravity models through fetchAvailableModels, while filtering unstable/internal IDs and falling back to a curated list if discovery fails.
• Preserves provider-supplied tool call IDs through the Gemini Code Assist translation path, which matters for Claude-backed Antigravity models.

Local verification

Automated checks run locally on Windows:

uv run --extra dev python -m pytest tests\agent\test_antigravity_cloudcode.py tests\agent\test_gemini_cloudcode.py tests\agent\transports\test_chat_completions.py tests\hermes_cli\test_model_provider_persistence.py -q -o addopts= --timeout=60 --timeout-method=thread -k "not save_uses_0600_permissions"
187 passed, 1 deselected

uv run --extra dev ruff check agent\antigravity_oauth.py agent\antigravity_code_assist.py agent\antigravity_cloudcode_adapter.py agent\gemini_cloudcode_adapter.py hermes_cli\auth.py hermes_cli\auth_commands.py hermes_cli\config.py hermes_cli\providers.py hermes_cli\models.py hermes_cli\main.py tests\agent\test_antigravity_cloudcode.py tests\agent\test_gemini_cloudcode.py tests\agent\transports\test_chat_completions.py tests\hermes_cli\test_model_provider_persistence.py
All checks passed

python -m compileall agent\antigravity_oauth.py agent\antigravity_code_assist.py agent\antigravity_cloudcode_adapter.py agent\gemini_cloudcode_adapter.py hermes_cli\auth.py hermes_cli\auth_commands.py hermes_cli\config.py hermes_cli\providers.py hermes_cli\models.py hermes_cli\main.py
passed

Manual smoke verification was also done with an isolated HERMES_HOME:

DISCOVERY_CLIENT_ID True
DISCOVERY_CLIENT_SECRET True
REFRESH_OK True
MODELS
  gemini-3-flash-agent
  gemini-3.5-flash-low
  gemini-pro-agent
  gemini-3.1-pro-low
  claude-sonnet-4-6
  claude-opus-4-6-thinking
  gpt-oss-120b-medium

TEXT_CONTENT HERMES_AG_DISCOVERY_OK
STREAM_CONTENT HERMES_AG_STREAM_DISCOVERY_OK
TOOL_CALL_NAME lookup_weather
TOOL_FINAL_CONTENT HERMES_AG_TOOL_DISCOVERY_OK

Notes

This intentionally does not depend on the Antigravity CLI token file layout. On the Windows environment used for testing, authenticated agy state appeared to live outside ~/.gemini/antigravity-cli/antigravity-oauth-token, so this implementation keeps Hermes tokens self-contained while still sourcing the desktop OAuth client identity from the installed Antigravity CLI.

[alt-glitch]

Competing with #29385 (same Antigravity OAuth provider, different auth approach). Both address #29294 (Gemini CLI sunset 2026-06-18). This PR owns the PKCE flow in Hermes; #29385 reads credentials from the agy binary. Maintainer should pick one approach.

[pmos69]

Both #29385 and #29474 close #29294 and take the same overall direction — an opt-in Antigravity provider that leaves gemini and google-gemini-cli untouched. They diverge on a handful of design axes. This table lays those out so the choice of auth boundary and discovery philosophy is explicit; each row is a real tradeoff, not a defect in either PR.

Area	#29385 — read agy credentials	#29474 — Hermes-owned PKCE	What the choice trades off
Credential source	Reads the Antigravity CLI token file (~/.gemini/antigravity-cli/antigravity-oauth-token).	Runs its own PKCE flow; discovers the OAuth client (ID/secret) from an installed agy or HERMES_ANTIGRAVITY_* env.	Minimal OAuth surface in Hermes vs. not depending on a pre-existing agy token file (observed missing on at least one Windows setup during testing).
Initial login	User runs agy first; Hermes only reads/refreshes.	hermes model / hermes auth can complete login directly.	Login owned by the official CLI (conservative, no consent flow in Hermes) vs. self-contained login with no separate interactive agy session.
agy dependency	Requires agy installed and authenticated, token file present.	Requires agy installed or env overrides for client creds; does not need agy authenticated.	Both lean on agy for OAuth client details; they differ in whether agy must also hold a live login.
Token storage	Antigravity CLI's own store.	Separate ~/.hermes/auth/antigravity_oauth.json.	Single shared token vs. Hermes-isolated, per-profile tokens with no external-store coupling.
Model list	Curated Hermes list.	Live fetchAvailableModels discovery, filtered, with curated fallback.	Never exposes internal/unstable IDs vs. surfaces account-entitled models (which can include families absent from the Gemini CLI path), at the cost of needing filters.
Adapter shape	Reuses GeminiCloudCodeClient with a credential_source switch.	Separate Antigravity adapter/helpers, reusing Gemini translation where it applies.	Less new code, behavior close to the known Gemini CLI path vs. Antigravity's distinct endpoint/headers/scopes/catalog kept visibly separate from Gemini CLI.
Non-streaming	Verified SSE, aggregated for non-streaming.	Native generate/stream paths through the adapter.	Both defensible; #29385's is the more cautious if only streamGenerateContent?alt=sse was verified.
External-CLI state	Does not persist discovered project IDs into the agy token store.	Does not touch the agy store at all; persists only in Hermes-owned creds.	Same safety outcome reached two ways — explicit non-mutation vs. no shared file to mutate.

Short version: #29385 optimises for a minimal integration that piggybacks on the official agy login; #29474 optimises for a self-contained, first-class Hermes provider with live model discovery and isolation from external-CLI state. Both are reasonable — the decision is mainly which auth boundary the project wants to own.

[GalegO]

Documentation: Antigravity (Windows) Integration in Hermes

This document records the necessary modifications to make the google-antigravity provider compatible with the Windows environment, natively reading access keys from agy.exe (Antigravity CLI) and fixing specific parameters for the Code Assist API.

---

1. The Problem with the Original Pull Requests

Hermes relied on two major PRs that introduced the google-antigravity provider, but neither worked perfectly in isolation within the Windows 11 64bits environment:

PR 29474: Browser-Based OAuth Approach

This PR implemented a native adapter inside Hermes with an OAuth flow identical to the Google Gemini CLI (opening the browser, exchanging codes for tokens, and writing to a .json file).

• Why it failed: The agy.exe binary (used in Antigravity) has its OAuth Client Secret obfuscated or not publicly distributed. Therefore, when Hermes attempted to make the token exchange request by sending an empty Client Secret (or "not_a_secret"), the backend rejected it with an invalid_client error.

PR 29385: Binary Reading Approach (Linux/macOS)

This PR suggested not rebuilding the OAuth flow from scratch, but rather reading the token that the agy binary itself had already authenticated.

• Why it failed (on Windows): The original code for this PR assumed that tokens were saved in a simple hidden .json text file (as happens on macOS and Linux). However, on Windows, agy.exe uses the Windows Credential Manager securely under the gemini:antigravity key.

---

2. The Implemented Hybrid Solution

We took the excellent architecture and adapters from PR 29474 and implemented the credential interception logic from PR 29385, but completely rewritten specifically for Windows cryptography and credential vault APIs.

Change 1: agent/antigravity_oauth.py (The Windows Vault)

• Removed the entire manual flow of opening the browser (start_oauth_flow).
• Implemented native reading via the ctypes library and advapi32.dll.
• Hermes now calls the Windows CredReadW API to successfully extract the JSON blob corresponding to gemini:antigravity.
• Auto-Refresh: If the token read from Windows is close to expiring, we added logic to run subprocess.run(["agy", "--print", " "]) in the background. This forces the Antigravity CLI to perform the renewal via the backend and update the Windows Credential Manager. Hermes then simply reads the updated version!

Change 2: Code Assist API Configuration

We found two minor payload and endpoint details (which were correct in PR 29385 but were lost or contained errors in PR 29474):

agent/antigravity_code_assist.py

The base URL was pointing to a "sandbox" environment that was not responding (returning 404 Not Found).

- ANTIGRAVITY_CODE_ASSIST_ENDPOINT = "https://daily-cloudcode-pa.sandbox.googleapis.com"
+ ANTIGRAVITY_CODE_ASSIST_ENDPOINT = "https://daily-cloudcode-pa.googleapis.com"

agent/antigravity_cloudcode_adapter.py

The Code Assist API for the Antigravity entity requires specific identification metadata (requestId, requestType, and userAgent) at the root of the payload. We updated the request wrapper to comply with these backend requirements:

wrapped = {
    "project": ctx.project_id,
    "requestId": self._next_antigravity_request_id(),
    "model": model,
    "userAgent": "antigravity",
    "requestType": "agent",
    "request": inner,
}

Change 3: User Configuration (config.yaml)

Finally, we identified that the user's personal configuration file (C:\Users\<username>\AppData\Local\hermes\config.yaml) used the display name (Gemini 3.1 Pro (Low)) instead of the technical ID (gemini-3.1-pro-low). Hermes sent the friendly name to the backend, which also resulted in a 404 Requested entity was not found error. The config.yaml file has been normalized.

---

Tip

Backup Created!
For security purposes, the three key integration files (antigravity_oauth.py, antigravity_code_assist.py, and antigravity_cloudcode_adapter.py) have been copied to the backup folder at C:\Users\<username>\OneDrive\Dev\FORK\Hermes\antigravity_windows_backup\.

Files changes during the process:
antigravity_windows_backup.zip

V2: Working on Docker in Ubuntu (VPS)
Install AGY CLI and auth on Linux bash, not into Docker.
hermes_agy_docker_linux.zip

[w0l4i]

python -m compileall agent\antigravity_oauth.py agent\antigravity_code_assist.py agent\antigravity_cloudcode_adapter.py agent\gemini_cloudcode_adapter.py hermes_cli\auth.py hermes_cli\auth_commands.py hermes_cli\config.py hermes_cli\providers.py hermes_cli\models.py hermes_cli\main.py

please add antigravity on hermes model so we can login and use antigravity gemeni cli is going down 18jun

[teknium1]

Merged via #50454 — #50454

Your native Antigravity OAuth provider was salvaged onto current main with your authorship preserved (commit 8baa4e997, rebase-merge). We kept your Hermes-owned PKCE flow and own-token-store design as the foundation, and added three follow-ups on top:

• Registered the google-antigravity ProviderProfile (the original wiring touched auth/runtime/providers but never registered the profile, so the provider was invisible to the model picker / list_providers()).
• Baked in the public Antigravity desktop OAuth client + default Code Assist project as the final fallback (env → discovered-from-agy → public default), so users without agy installed can authenticate directly. PKCE makes the installed-app secret non-confidential — same posture as the gemini-cli creds we already ship.
• Relocated the model-setup flow into hermes_cli/model_setup_flows.py (flows were extracted out of main.py after you forked) and stopped Antigravity's borrowed Claude/Gemini/GPT-OSS catalog from hijacking bare model aliases away from their native vendor.

google-gemini-cli is left untouched — it still serves Enterprise Code Assist users, who were not part of the June 18 consumer sunset. Thanks for the solid foundation here.