Clarification Request: Is local IPC/PTY wrapping of `agy` CLI for open-standard editor bridges (e.g., ACP) ToS compliant?

Google Antigravity
1

Hi Google AI & Antigravity team,

I’m the developer of agy-acp, an open-source bridge that enables editors supporting the Agent Client Protocol (ACP)—such as Zed, Neovim, and other developer tools—to work with the official Google Antigravity agy CLI.

Before continuing development, I’d like to make sure the project aligns with the intended usage model for agy and does not violate the Antigravity Terms of Service.

How agy-acp Works

For transparency, here’s the architecture:

  • Local-only, single-user. agy-acp runs entirely on the user’s machine as a local ACP server (for example, via npx agy-acp). It does not provide a hosted service, proxy requests, or share access between users.
  • Uses the official CLI. It launches the user’s locally installed agy binary in a PTY subprocess (for example, agy --prompt-interactive ...) and relies entirely on the user’s existing agy login session for authentication.
  • No credential handling. The project never requests, stores, or forwards authentication credentials or tokens.
  • Protocol bridge. Its primary purpose is to translate communication between the official agy CLI and the ACP protocol so compatible editors can provide a native chat and streaming experience.
  • Optional local state synchronization. To keep the editor UI synchronized with the CLI, the project can read conversation metadata generated locally by agy (currently stored as SQLite databases under ~/.gemini/antigravity-cli/conversations/).

Questions

1. Local CLI Integration

Is invoking the official agy CLI through a local PTY/subprocess for a single-user editor integration considered an acceptable use of the CLI under the Antigravity Terms of Service?

2. Reading Local Conversation State

Is reading the locally generated conversation database solely for local UI synchronization considered an acceptable integration pattern, or should third-party tools avoid inspecting these files?

If this is not recommended, is there an alternative or planned API for accessing conversation state?

3. Automated Local Invocation

Does repeatedly invoking agy from a local editor integration (rather than manually from a terminal) risk triggering anti-automation or abuse detection for legitimate developer accounts?

4. Future Integration Guidance

Are there plans for the agy CLI to provide native support for open editor protocols such as ACP, or is there an officially recommended integration approach for third-party editor developers?

My goal is to build an open-source editor integration that provides a great developer experience while fully respecting Google’s intended usage model and policies. I’d greatly appreciate any guidance or recommendations from the Antigravity team.

Thank you!

2

Hi @shindgew,

Here is clarification on your integration:

1. **ToS Compliance (Local CLI Wrapping):**

- **Yes, your described pattern is compliant.** The ToS restriction on third-party access tools is aimed at credential harvesting, unofficial API reverse-engineering, and multi-tenant proxying.

- Spawning the official, unmodified `agy` binary locally as a single-user child process/PTY under the user’s own `agy login` session complies with single-user usage, provided tokens are not extracted, stored, or forwarded.

2. **Local SQLite State:**

- Reading `~/.gemini/antigravity-cli/conversations/` for read-only UI syncing is permissible, but note that the local database schema is an internal implementation detail and can change across releases without notice.

3. **Rate Limits & Abuse Detection:**

- Interactive turns driven by normal user prompts will not trigger abuse flags; they simply draw against the user’s standard account quota.

4. **Native ACP Support:**

- Google already maintains and distributes an official **Antigravity ACP Server** (used by editors like Zed). Connecting directly to the official ACP server binary is the officially supported path for ACP-based editor integrations.