Hi,
I’m looking at Antigravity CLI’s documented headless mode for integration into an external orchestration system.
The documentation already shows that agy -p can be invoked non-interactively, can emit json / stream-json, and uses cached credentials when the CLI has previously been authenticated interactively.
So I’d like to clarify the intended support boundary for this use case:
- Is it supported for another local application/orchestrator to launch the official Antigravity CLI in headless mode as a bounded execution worker, while Antigravity itself retains the user’s Google authentication?
If so, when the user is signed in through the normal Antigravity account flow, does such headless usage consume the same account/subscription entitlement and limits as ordinary interactive CLI usage?
I am specifically not asking about extracting OAuth tokens, reusing Antigravity credentials in a third-party client, or calling Antigravity backend services directly. The external application would only invoke the official agy binary.
- Is --output-format stream-json intended to provide enough information for audit-grade reconstruction of a run?
For example, can a host reliably reconstruct the ordering of tool calls/results, file changes, permission decisions, subagent activity, retries/recovery, cancellation/interruption, and other runtime state transitions?
If some internal Antigravity runtime events are intentionally omitted or coalesced before they reach stream-json, is there a supported tracing/debugging interface for deeper observability?
I’m trying to understand the intended boundary between:
external orchestration of the official Antigravity runtime
and
unsupported reuse of Antigravity authentication or backend access.
Thanks — any clarification or relevant documentation would be appreciated.