feat(antigravity): support native Go agy acp (antigravity-cli v1.4.12+) as first-class ACP runtime

[mahmoodnizamani94-png]

T3 Code currently provisions and runs the Python .par + localharness_external bundle (agy_acp_server.par v1.4.1, ~1.06 GB on disk) for the Antigravity provider.

Google's Antigravity CLI (agy, v1.4.12+, google3/third_party/jetski/cli/acp/) ships a single native Go binary (agy acp, ~234 MB) with the ACP server and Jetski harness compiled in-process.

Benchmarks (Linux x64)

Metric	agy_acp_server.par (v1.4.1)	agy acp (v1.4.12)	Improvement
Disk size	1.06 GB	234 MB	4.5x smaller
Cold initialize	~3,030-3,500 ms	~260-500 ms	~7-11x faster
Warm session/new	~1,390-1,480 ms	~30-55 ms	~25-45x faster
Memory (RSS)	~453-578 MB (2+ procs)	~215-279 MB (1 proc)	~2.1-2.5x less RAM

Current Compatibility Gaps in T3 Code

1. agentInfo.name check (AntigravityInstallation.ts): agy acp v1.4.12 returns "Antigravity ACP Server" instead of "antigravity-acp".
2. MCP tool recognition (packages/provider-acp/src/server/runtimeModel.ts): agy acp emits title: "Run mcp_t3-code_<tool>" without _meta.is_mcp_tool_call. extractTitleCandidate() strips running|call|... but not run, so T3 Code treats MCP tools as raw dynamic_tool calls.
3. configOptions IDs: agy acp uses thought_level instead of thinking_level and omits mode.
4. Per-instance Auth Storage: agy acp uses OS keyring or --gemini-dir=<relpath>/oauth_creds.json rather than GEMINI_HOME + AGY_ACP_FORCE_FILE_STORAGE=1 (acp_token.json).

Questions

1. Could T3 Code prioritize supporting native agy acp as a first-class Antigravity runtime?
2. Which runtime method (agy_acp_server.par automatic managed flow vs agy acp CLI) is safer and recommended for Google account standing and multi-account isolation?

[keejkrej]

Beyond performance and disk size, supporting agy acp is also needed for Linux ARM64 systems with 16 KiB (or 64 KiB) kernel page sizes (Apple Silicon / Asahi Linux, Raspberry Pi 5, Omarchy ARM64, etc.), where the managed agy_acp_server.par (v1.4.5) binary is completely unusable and immediately SIGABRTs on startup:

F1105 02:32:28.785255   47538 page-size.cc:19] Check failed: sysconf(_SC_PAGE_SIZE) == kPageSize (16384 vs. 4096) Compile-time page size does not match runtime page size
*** Check failure stack trace: ***
    @     0xaaab0e47bf30  absl::log_internal::LogMessage::Flush()
    @     0xaaab1a034dec  bamm2::internal::google_init_module_bamm2_init_verify_page_size()
    @     0xaaab0ea9b3a8  GoogleInitializer::TypeData::RunIfNecessary()
    @     0xaaab11020194  GoogleInitializer::RunInitializers()
    @     0xaaab197bc53c  RealInitGoogle()

The legacy Python .par archive links Google's internal C++ bamm2 allocator with a hardcoded 4096-byte page-size assertion (also tracked upstream in agentclientprotocol/registry#547).

By contrast, the native Go agy CLI (v1.5.0+ / v1.5.1, which officially added agy acp and removed the third-party client model allowlist) is built with 64 KiB ELF alignment and does not use bamm2, so agy acp works out of the box on 16 KiB page-size linux-arm64 kernels.