Clarification Request: Is a Plugin Sidecar Allowed to Use Antigravity Language Server GetModelResponse for PreToolUse Security Classification?

Google Antigravity
1

Clarification Request: Is a Plugin Sidecar Allowed to Use Antigravity Language Server GetModelResponse for PreToolUse Security Classification?

I would like to clarify whether the following Antigravity plugin architecture is permitted under the Antigravity Additional Terms.

The intended use case is not to expose Antigravity models to another AI client, create a proxy API, reuse Antigravity OAuth credentials externally, or provide inference to third-party applications.

The goal is only to implement an automatic permission/security classifier for Antigravity itself, similar in concept to an “auto approve safe actions, ask for risky actions” mode.

The proposed flow is:

Antigravity Agent
        │
        │ proposes a tool call
        ▼
PreToolUse Hook
        │
        │ ambiguous permission decision
        ▼
Antigravity-managed Plugin Sidecar
        │
        │ localhost only
        ▼
Antigravity Language Server
        │
        │ GetModelResponse
        ▼
small model classification
        │
        ▼
allow / ask / deny

More specifically:

  • The plugin is installed and executed inside Antigravity.

  • Antigravity manages the plugin sidecar lifecycle.

  • The sidecar runs locally and communicates only over loopback.

  • The PreToolUse hook sends the proposed tool call to the local sidecar.

  • The sidecar uses the Language Server connection information available in the Antigravity-managed environment to call the local Language Server’s GetModelResponse RPC.

  • The model is used only to classify the safety of the tool call and return a result such as allow, ask, or deny.

  • No Google OAuth access token is extracted, copied, stored, or exposed to the plugin.

  • The plugin does not call Google backend endpoints directly.

  • It does not expose an OpenAI-compatible API or any other general-purpose model API.

  • It does not provide model access to Claude Code, Codex, OpenCode, OpenClaw, or another external AI agent.

  • It is not multi-user, hosted, resold, or used for quota pooling.

  • The resulting model decision is used exclusively inside the same Antigravity workflow that initiated the tool call.

The reason for asking is that GetModelResponse appears to be a Language Server RPC rather than a currently documented public Plugin/Sidecar API.

I understand that Antigravity officially supports Plugins, Hooks, Sidecars, agentapi, and the agy CLI, while the Additional Terms restrict certain forms of third-party access, credential reuse, unofficial clients, and private API access.

Could you please clarify the following?

  1. Is a third-party Antigravity plugin permitted to call the local Antigravity Language Server’s GetModelResponse RPC when the call is made entirely inside an Antigravity-managed plugin/sidecar and solely for extending Antigravity itself?

  2. Does the answer change if the plugin never receives or extracts the user’s Google OAuth credentials and communicates only with the locally running Antigravity Language Server?

  3. Is the fact that GetModelResponse is currently undocumented sufficient to make this use unsupported or prohibited, even though the plugin itself is running through Antigravity’s official Plugin/Sidecar system?

  4. If direct use of GetModelResponse is not permitted, should plugins that need model inference use only documented interfaces such as agentapi or the official agy CLI?

  5. Is there, or is there planned to be, an officially supported lightweight model-inference API for Plugins/Sidecars for use cases such as permission classification, moderation, routing, or other small internal decisions?

I am specifically looking for clarification on the boundary between:

third-party software using Antigravity as an external model provider

and:

an Antigravity plugin using an internal model call solely to implement functionality inside Antigravity itself

A clear answer would also be useful for plugin developers who want to build permission systems and other model-assisted extensions without accidentally relying on an interface that Google considers outside the supported or permitted surface.

Thank you.

2

Hi @Windy_Sin,

This is one of the most well-formulated architectural and compliance questions posted on the forum. The problem you are solving—automatic, intelligent permission gating at the PreToolUse stage—is a major UX necessity for autonomous agents.

While we await formal legal guidance from the Google team, here is an engineering and architectural perspective on the trade-offs of using GetModelResponse versus supported alternatives:

1. The Terms of Service & Technical Fragility Reality

Even though your sidecar operates entirely on loopback without leaking OAuth tokens or reselling inference, relying on GetModelResponse carries significant risks:

  • Private Contract vs Public Surface: Google’s Terms of Service historically distinguish between documented developer interfaces (Plugins, Hooks, Sidecars, agentapi, agy CLI) and internal daemon protocols. Undocumented language server RPCs are considered private implementation details.
  • The Weekly Breaking-Change Trap: Because internal Language Server RPCs are not governed by public API semantic versioning, any standard Antigravity update can rename the RPC, alter the Protobuf signature, or enforce internal IPC handshake tokens. Building on private RPCs creates a high ongoing maintenance burden.

2. The Hidden Latency Penalty of In-Line LLM Gating

From an agent performance perspective, routing every ambiguous PreToolUse event through an LLM inference call introduces 500ms to 1,200ms of latency per tool call.

In fast-paced workflows where an agent runs multiple inspections or search passes in a single turn, this compound latency becomes noticeable very quickly.

3. Two Fully Compliant & Supported Alternatives Today

If you want to ship a secure, production-grade permission classifier today without ToS ambiguity:

Option A: Deterministic Mechanical Gating (Sub-Millisecond & Zero-Cost)

Rather than asking a model to classify intent on every tool invocation, you can implement a deterministic, state-machine gate.

In our own open-source workbench architecture (RFC-003: Deterministic Two-Stage Planning Gate), we separate operations into distinct stages:

  • Read-only inspection tools (search, AST lint, file view) execute with zero prompts.
  • Mutating/write tools (file replacement, terminal execution) are mechanically locked until an explicit human approval or plan consensus is reached.
  • Execution Latency: <0.3ms (pure local logic, zero LLM tokens, zero network round-trips).

Option B: Official Developer API via Gemini Flash-Lite

If semantic classification is strictly required (e.g. evaluating natural language intent against security policies):

  • Use the official @google/genai SDK pointing to gemini-2.0-flash-lite using a standard Google AI Studio API key.
  • Flash-Lite operates with sub-200ms latency, costs fractions of a cent per thousand classifications, and operates 100% within the documented, supported Google developer surface with full SLA guarantees.

4. Seconding Your Request to the Antigravity Team

Your Question #5 is the critical takeaway for the platform roadmap:

“Is there, or is there planned to be, an officially supported lightweight model-inference API for Plugins/Sidecars for use cases such as permission classification, moderation, routing, or other small internal decisions?”

Having a first-party, supported context.classify() or local small-model hook inside the official Plugin SDK would eliminate the need for workarounds and empower developers to build intelligent, autonomous security guardrails safely.

3

Hi @Windy_Sin,

Welcome to the Forum and thank you for the incredibly clear architectural breakdown and specific questions.

The Boundary: Public Extension Surfaces vs. Internal Daemon RPCs

While we recognize that your plugin runs strictly locally over loopback, does not extract user OAuth credentials, and uses model decisions solely within Antigravity, the platform boundary is defined by supported public extension interfaces vs. private internal daemon RPCs:

  • Supported: Extending Antigravity through documented extension surfaces (Hooks, Plugins, Sidecars, agentapi, the agy CLI, and the Antigravity Python SDK).
  • Not Supported / Prohibited: Calling undocumented internal Language Server RPC methods (such as GetModelResponse) directly—even over localhost from an Antigravity-managed sidecar.

Answers to Your Specific Questions

Is a third-party Antigravity plugin permitted to call GetModelResponse directly from an Antigravity-managed sidecar for internal extension functionality?

No. Calling GetModelResponse (or any other internal Language Server RPC) directly from a plugin or sidecar is not supported or permitted.

Although Antigravity injects environment variables such as ANTIGRAVITY_LS_ADDRESS and ANTIGRAVITY_CSRF_TOKEN into the managed sidecar environment, these exist solely as internal transport plumbing for the bundled agentapi CLI and official Sidecar SDK tooling—not as a public RPC contract for direct invocation.

Does the answer change if the plugin never extracts OAuth tokens and only communicates with the local Antigravity Language Server?

No. While avoiding OAuth credential extraction and external proxying prevents third-party client spoofing violations, invoking private local Language Server endpoints directly still bypasses the supported extension layer.

Because internal RPC schemas, service descriptors, and model routing identifiers are private implementation details subject to breaking changes without notice or deprecation cycles, relying on them creates high technical fragility and may trigger daemon integrity protections.

Is the fact that GetModelResponse is undocumented sufficient to make this usage unsupported or prohibited?

Yes. Plugins, hooks, and sidecars must only interact with Antigravity through officially documented and supported interfaces. Undocumented Language Server endpoints are strictly internal communication channels between the Antigravity client and the local daemon.

Should plugins only interact through documented interfaces like agentapi or the agy CLI?

Yes. Programmatic interaction with the runtime from a plugin or sidecar should follow documented surfaces:

  • For synchronous PreToolUse command hooks: We recommend keeping hook scripts and sidecar endpoints deterministic (e.g., command/path allowlists, regex inspection, AST linting, and rule-based heuristics returning {"decision": "allow" | "ask" | "deny" | "force_ask", "reason": "..."}). Note that agentapi (new-conversation, send-message, get-conversation-metadata) is intended for asynchronous conversation orchestration rather than low-latency synchronous classification inside a blocking hook.
  • If your sidecar requires custom LLM classification: Your sidecar should invoke the official Google Gemini API (such as gemini-2.0-flash-lite via @google/genai or the google-genai Python SDK) using a standard, user-configured Gemini API key, rather than routing requests through internal Language Server endpoints.

Is there, or is there planned to be, an officially supported lightweight model-inference API or feature for PreToolUse classification?

We are actively tracking community requests for first-party model-assisted evaluation in hooks. Currently available capabilities include:

  • Terminal Sandbox (proceed-in-sandbox): In Antigravity’s Agent Permissions & Security settings, terminal commands can run inside a secure sandbox by default without prompting, escalating to human confirmation only when an action attempts to step outside sandbox boundaries.
  • Antigravity Python SDK (policy.auto()): If you orchestrate agents programmatically via the Antigravity Python SDK, policy.auto() provides built-in model-assisted pre-tool safety assessment out of the box.

We have logged your feedback regarding native prompt-based evaluation for hooks and lightweight inference helpers for sidecars. Please keep an eye on the official Antigravity Changelog and Hooks documentation for future updates and release announcements!

4

English Version

Hi @chunduriv,

Thank you for the clear and detailed clarification regarding the boundary between public extension surfaces and internal Language Server RPCs. We completely respect the distinction and understand why undocumented daemon endpoints should not be called directly.

To be direct about our core motivation: what we are ultimately trying to achieve with this plugin—and what we believe Antigravity fundamentally needs—is an LLM-powered contextual permission evaluator, directly analogous to Claude Code’s Auto mode or Codex’s “Approve for me”.

Whether this arrives as a first-party, native “Auto / Approve for me” mode within Antigravity, or as an officially supported, low-latency inference helper for sidecar hooks backed by the active IDE session, this capability is critical for unlocking truly fluid agentic development.

Static command policies alone do not solve the permission UX problem for long-horizon agentic workflows, which is why we were exploring model-assisted pre-tool evaluation in the first place:

  1. The Core Pain Point: Dozens of Interruptions in Multi-Step Tasks

    In extended workflows, relying strictly on deterministic rules (whitelists, regex, AST linting) forces a binary choice: either constantly interrupt the developer with dozens of repetitive approval prompts for benign, routine sub-actions, or bypass safeguards entirely. Constant approval friction defeats the entire premise of autonomous long-running tasks.

  2. Why Intent and Context Require an LLM

    Deterministic rules evaluate commands in isolation and cannot understand developer intent. Commands like cleanup scripts, build commands, or package installations are routine within the context of a specific build or refactor goal, but look indistinguishable from suspicious actions to a static heuristic. A lightweight LLM evaluator that takes into account the user’s high-level goal, current workspace diffs, and the immediate operational context can reliably judge whether a command is aligned with the active task.

  3. Bridging the Gap Between Sandboxing and Unconstrained Execution

    While proceed-in-sandbox is a welcome feature, sandboxing is an isolation mechanism, not an intent validator. Conversely, unconstrained execution modes carry clear operational risks. A context-aware auto-approval mechanism hits the ideal middle ground: allowing agents to execute complex tasks smoothly from start to finish, while proactively escalating to human confirmation only when an action is genuinely destructive, out-of-scope, or high-risk.

Thank you again for passing this feedback to the runtime and product teams. We are eager to see how the platform evolves in this direction!

Best regards,