feat(antigravity): add experimental Antigravity agent integration

[Joseph19820124]

Summary

Adds Dockerfile.antigravity that bridges OpenAB to Google's Antigravity backend by re-targeting the existing gemini-cli --acp implementation against daily-cloudcode-pa.googleapis.com. No new Rust code, no new protocol — the agent still speaks ACP-over-stdio just like Dockerfile.gemini.

⚠️ EXPERIMENTAL — bridge while we wait for upstream ACP support.

Google's official agy CLI shipped at v1.0.0 in May 2026, but it does not yet expose --acp / stdio JSON-RPC mode (verified via --help + binary strings inspection — only -p/--print exists for non-interactive use, which can't drive OpenAB's streaming + tool-approval pipeline).

Upstream feature request: google-antigravity/antigravity-cli#31 — filed today.

Once agy adds --acp, this image collapses to a thin wrapper installing the official agy binary (see "Future replacement" in docs/antigravity.md).

What this unlocks

For users with an Antigravity subscription, this gives OpenAB Discord / Slack / Custom Gateway bots access to:

• Gemini 3 Pro / Gemini 3.5 Flash
• Claude 4.6
• Other models hosted by Antigravity

… without paying API rates, and without OpenAB needing protocol changes.

How it works

Antigravity reuses the same wire protocol as gemini-cli:

POST /v1internal:streamGenerateContent?alt=sse

…on a different host (daily-cloudcode-pa.googleapis.com instead of cloudcode-pa.googleapis.com) with a different OAuth client. So:

1. We install @google/gemini-cli (whose --acp mode OpenAB already integrates).
2. At container startup, an entrypoint script grep-discovers gemini-cli's OAuth + endpoint constants in its bundled JS chunks and rewrites them to point at Antigravity.
3. OpenAB sees an ordinary gemini --acp subprocess.

Why not invoke agy directly

Verified against v1.0.0:

agy mode	Streams	Tool approval	Cancel	OpenAB-compatible?
TUI (default)	✅	✅	✅	No (terminal-only)
-i / --prompt-interactive	✅	✅	✅	No (terminal-only)
-p / --print	❌	❌	❌	No (one-shot, no events)

agy v1.0.0 has no stdio JSON-RPC surface. The patched-gemini-cli approach is the only way to deliver Antigravity backend access to OpenAB users today without changes to OpenAB's ACP harness.

Security / secret-hygiene

• Zero literal Antigravity OAuth secrets in this image. Supplied at deploy time via ANTIGRAVITY_OAUTH_CLIENT_ID / ANTIGRAVITY_OAUTH_CLIENT_SECRET env vars (Helm secretEnv pattern, see values.yaml).
• Zero literal gemini-cli OAuth values either — the patch script greps gemini-cli's own bundle at container startup to discover the default values it needs to rewrite. Nothing OAuth-looking ends up in the Dockerfile, so GitHub's secret-push-protection doesn't trigger.

Files changed

File	Change
Dockerfile.antigravity	new — extends Dockerfile.gemini template with runtime patch + entrypoint
docs/antigravity.md	new — full docs incl. limitations + agy capability matrix + future-replacement plan
charts/openab/values.yaml	adds commented antigravity: example block (same style as opencode / grok / hermes)
AGENTS.md	updates "7 Dockerfiles" → 10 (also picks up grok / hermes which weren't listed there)

Compatibility / risk

Item	Risk
gemini-cli bundle layout change	Patch script fails loudly at container start with a clear error pointing at GEMINI_CLI_VERSION — no silent corruption.
Antigravity API contract change	daily-cloudcode-pa.googleapis.com/v1internal is an internal API; clearly marked in docs.
agy adds --acp upstream	Image becomes a thin wrapper around the official binary (see future-replacement section in docs/antigravity.md).
OpenAB Rust code	Zero changes. ACP protocol unchanged.
Existing agents	Zero changes — no shared files touched besides AGENTS.md count and a new commented block in values.yaml.

Test plan

• CI: image build for Dockerfile.antigravity succeeds
• Manual: container starts and patch script logs patch complete; endpoint=https://daily-cloudcode-pa.googleapis.com
• Manual: with valid Antigravity OAuth creds, gemini --acp initializes a session against the Antigravity backend
• Manual: Discord round-trip — message in allowed channel produces an Antigravity-backed response
• Negative: missing ANTIGRAVITY_OAUTH_CLIENT_ID makes the patch script exit with the required-var message before openab starts

Open questions for reviewers

1. Helm schema — values.yaml uses agents.antigravity.* with command: gemini, args: [--acp]. Should there be a dedicated agents.antigravity schema, or is "reuse the gemini schema with an env-vars overlay" acceptable for now (given the actually-invoked binary still is gemini)?
2. CI matrix — should Dockerfile.antigravity be added to the release workflow's image-build matrix now, or wait until agy adds --acp and the Dockerfile simplifies?
3. Naming — antigravity keeps the future-facing name. Alternative: agy to match Google's binary. Easy to rename pre-merge.

Happy to iterate on any of the above.

Related

• Upstream feature request: google-antigravity/antigravity-cli#31 — add --acp flag for ACP orchestrator compatibility
• Background: I/O 2026 highlights, Gemini CLI → Antigravity CLI transition

🤖 Generated with Claude Code

[github-actions]

⚠️ This PR is missing a Discord Discussion URL in the body.

All PRs must reference a prior Discord discussion to ensure community alignment before implementation.

Please edit the PR description to include a link like:

Discord Discussion URL: https://discord.com/channels/...

This PR will be automatically closed in 3 days if the link is not added.

[Joseph19820124]

Closing — superseded; will revisit once agy adds upstream --acp support (google-antigravity/antigravity-cli#31).