Gemini CLI and Antigravity

Review changed Gemini CLI and Antigravity extensions, skills, and MCP servers before launch through the Guard launcher shim.

Updated:
Applies to:
Guard 3.x
Maintained by:
HOL Guard Team
Source:
github:hashgraph-online/hol-guard
Also available:
MarkdownDocs library

Use this guide when Gemini CLI or Antigravity loads local extensions, skills, or MCP server declarations and you want Guard to review changed surfaces before launch.

Guard ships two separate adapters for these tools, with separate ids:

ToolIdExecutable
Gemini CLIgeminigemini
Antigravityantigravityantigravity

Both use the approval-center tier and the same protection path: a launcher shim and a scan before launch. Neither adapter writes hooks into the tool's config.

What Guard detects

Gemini CLI

The Gemini adapter reads the .gemini directory under your home directory and under the workspace:

  • .gemini/settings.json for MCP servers and hooks
  • .gemini/extensions/*/gemini-extension.json
  • .gemini/skills
  • skills under <workspace>/.agents/skills

For each extension manifest Guard records:

  • the extension name
  • the publisher when present
  • the optional contextFileName
  • embedded MCP server definitions under mcpServers

Antigravity

The Antigravity adapter reads:

  • the Antigravity user settings.json, from ~/Library/Application Support/Antigravity/User on macOS, ~/.config/Antigravity/User on Linux, and AppData/Roaming/Antigravity/User under your home directory on Windows
  • <workspace>/.vscode/settings.json, when it carries Antigravity settings
  • .gemini/antigravity/mcp_config.json under your home directory and the workspace
  • .gemini/antigravity/skills under your home directory and the workspace
  • the extension index at ~/.antigravity/extensions/extensions.json

Guard records installed extensions, MCP servers from each of those files, and skill documents.

How protection attaches

hol-guard install gemini and hol-guard install antigravity write one launcher shim each, guard-gemini and guard-antigravity, into ~/.hol-guard/bin. The shim, and hol-guard run, run Guard's pre-launch check and then start the real tool.

That makes the shim and hol-guard run the whole protection path. Launching gemini or antigravity directly skips the check, and Guard does not watch tool calls while the tool runs.

Approval model

Both tools use the approval-center tier:

  • Guard scans extensions, MCP registrations, and skills before launch
  • blocked changes go to the local approval center
  • hol-guard approvals resolves the same requests from the terminal

Neither tool exposes a native approval surface that Guard can answer.

Install and launch flow

For Gemini CLI:

hol-guard detect gemini --json
hol-guard install gemini --dry-run
hol-guard install gemini
hol-guard run gemini --dry-run
hol-guard run gemini
hol-guard approvals

For Antigravity, use the same commands with antigravity:

hol-guard detect antigravity --json
hol-guard install antigravity
hol-guard run antigravity --dry-run
hol-guard run antigravity

To check or remove either one:

hol-guard apps test gemini --json
hol-guard uninstall gemini
hol-guard apps test antigravity --json
hol-guard uninstall antigravity

Known limits

  • Gemini CLI: prompt submission and file reads and writes are not observable.
  • Antigravity: shell commands are not observable. Guard covers extensions and MCP registrations through the scan at launch time.
  • Gemini CLI: hooks declared in settings.json are recorded as artifacts, but Guard does not install its own.

Use a home directory or workspace with a real extension or MCP registration installed, then confirm:

  1. hol-guard detect <id> --json lists the extension manifest, skills, and MCP servers
  2. the first dry run records a receipt
  3. a changed extension or MCP entry routes to the approval center when policy blocks

Next guides