Enhancement: use the Antigravity CLI's built-in ACP server (agy acp) instead of the pinned 1.4.5 sidecar #1102

Summary

Antigravity CLI 1.5.0 added agy acp — a first-party ACP server built into the CLI itself (agy acp, stdio, images/embedded file context, steering a running turn, default/accept-edits/plan session modes, session/resume without replaying history, per-session model + thinking level, and agy acp --login for terminal sign-in over SSH).

codeg still installs and launches a standalone agy_acp_server 1.4.5 sidecar for the Google Antigravity agent. That means two parallel Antigravity installs, two settings files and two sign-ins. I'd like codeg to prefer the CLI's built-in ACP server when an agy ≥ 1.5.0 is available, so the agent shares the CLI's config and account.

Environment

• codeg 0.42.0 (Windows, Tauri build)
• Antigravity CLI 1.5.1 (agy --version via %LOCALAPPDATA%\agy\bin\agy.EXE), changelog confirms 1.5.0 = "Added acp to agy --help"
• OS: Windows 11 x64 (also reproducible reasoning for macOS/Linux)

Current behavior

src-tauri/src/acp/registry.rs:7093 — the Antigravity entry declares:

distribution: AgentDistribution::Binary {
    version: "1.4.5",
    cmd: "agy_acp_server",
    args: ANTIGRAVITY_LAUNCH_ARGS,   // `--uid=` on Linux only
    platforms: &[ /* https://dl.google.com/agy-extensions/releases/.../agy-acp-server-1.4.5-<platform>.zip */ ],
    dir_entry: Some(BinaryDirEntry { unix: "agy_acp_server.par", windows: "agy_acp_server.exe", .. }),
}

So codeg downloads a 1.4.5 archive and launches agy_acp_server, whose auth/config is a separate store: $GEMINI_HOME/antigravity-acp/settings.json (auth.type), plus the token files codeg writes itself (src-tauri/src/acp/antigravity_login.rs:2203 → antigravity-acp/acp_token.json, antigravity_acp/acp_business_token.json; comment at src-tauri/src/acp/connection.rs:469).

Meanwhile the CLI keeps ~/.gemini/antigravity-cli/settings.json (security.auth.selectedType, model, effort, trustedWorkspaces, …), its own sign-in, its own plugins/skills/MCP servers — and since 1.5.1 agy acp "offers every model available to your account to every ACP client", which the pinned sidecar does not.

Why this matters

1. Double login. Signing in to agy in a terminal does nothing for codeg's Antigravity agent, and vice versa. On a machine where the CLI is already signed in, selecting the codeg agent still asks for (or writes) a second credential set.
2. Config drift. Model / effort / trusted workspaces / plugins / skills / MCP servers configured in the CLI are invisible to the agent. Every change has to be made twice, in two formats.
3. Stale runtime + disk. ~195 MB unpacked on Windows (agy_acp_server.exe + localharness_external.exe) duplicating a tool the user already has, pinned at 1.4.5 while the CLI auto-updates to 1.5.x — so model list and behaviours diverge over time.
4. Model coverage. 1.5.1's agy acp exposes all account models; the 1.4.5 sidecar exposes the older fixed set.

Proposed change

Prefer the installed CLI, keep the sidecar as a fallback. Concretely, one of:

• a new AgentDistribution variant (e.g. PathBinary { cmd: "agy", args: ["acp"], min_version: "1.5.0" }) resolved through PATH / a user-configured path, or
• reuse AgentDistribution::Binary with cmd: "agy", args: ["acp"], platforms: &[] and treat "not found on PATH" as "offer the 1.4.5 sidecar download instead".

Suggested resolution order: user-configured agy path → agy on PATH with version ≥ 1.5.0 → pinned 1.4.5 sidecar download.

Useful flags agy acp already supports for per-workspace isolation, which map onto what codeg already does for dir-tree agents:

--app-data-dir <dir>   --gemini-dir <dir>   --cli_dir_name <name>
--ide-mcp-port <port>  --dangerously-skip-permissions  --login

--login is worth surfacing in the login UI: it is the supported terminal sign-in for editors connected over SSH or without a browser.

Pitfalls worth knowing

• ANTIGRAVITY_LAUNCH_ARGS passes --uid= on Linux only. agy acp has no --uid flag (it is an absl/InitGoogle flag of the sidecar), so the launch args must be per-distribution, not shared.
• agy acp reads the CLI settings (antigravity-cli/settings.json), not antigravity-acp/settings.json. The existing "AUTH IS A FILE, NOT AN ENV VAR" handling would need to detect an existing CLI sign-in instead of writing acp_token.json, and only fall back to the token path when the CLI is unauthenticated.
• Windows: agy.EXE is a native binary; version detection should use agy --help/changelog or a --version-equivalent (the CLI has no --version flag today, agy changelog | head -1 prints the version).
• Keep the sidecar path for users who never installed the CLI — it is currently the only zero-setup route.

Alternatives considered

• Status quo — works, but keeps the double install / double login problem above.
• CUSTOM ACP entry with command agy acp — already possible via custom_registry, but loses the managed install, the model picker metadata, the login flow and the per-agent settings UI, so it is not a real substitute for a first-class agent.

Willing to test

Yes — Windows 11 x64, codeg 0.42.0, agy 1.5.1 already installed and signed in; can also test the sidecar fallback by temporarily hiding agy from PATH.