Antigravity Integration

SigmaShake governs Google Antigravity with several layers. Each layer covers a different set of tool calls. No single layer covers every call, so read What SSG governs and what it does not before you rely on it.

Antigravity hooks.json hook — a PreToolUse and a PostToolUse entry in .agents/hooks.json. Antigravity runs ssg hook antigravity before a tool call.
MCP server — Antigravity can call ssg_* tools, for example ssg_evaluate.
User rules file — .sigmashake/antigravity-rules.md. You paste it into Antigravity user rules. It tells the model to call ssg_evaluate first.
Runtime hooks — a shell wrapper, a Node.js hook, and a Python hook. All three are shared with the Pi and Aider adapters.
C hooks (macOS and Linux only) — libssg and ssg-seccomp. They check file opens in a process that you start with them.

One command installs all five.

What SSG governs and what it does not

What the layers do

Layer	What it checks	Enforced by
`.agents/hooks.json` hook	A tool call, before it runs, when Antigravity sends it to the hook	`ssg hook antigravity` (a deny stops the call)
MCP server	A call to an `ssg_*` MCP tool	The model must choose to call the tool
User rules file	Model behavior	The model must follow the text. This is advice, not enforcement
Shell wrapper, Node.js hook, Python hook	Shell commands that run through the wrapper. File reads and writes in Node.js and Python processes that load the hook	The hook code in that process
`libssg` and `ssg-seccomp`	`open` and `openat` calls in a process that you start with the library or the wrapper	The library in that process

Coverage by operating system

Layer	Linux	macOS	Windows
`.agents/hooks.json` hook	Yes	Yes	Yes
MCP server entry	Yes	Yes	Yes
User rules file	Yes	Yes	Yes
Shell wrapper, Node.js hook, Python hook	Yes (`bash` wrapper)	Yes (`bash` wrapper)	Yes (`bash.cmd` and `bash.ps1` wrapper)
`libssg` (file-open check)	Yes (`LD_PRELOAD`)	Yes (`DYLD_INSERT_LIBRARIES`)	No. `ssg init` skips it
`ssg-seccomp`	Yes (seccomp-bpf, `openat` only; x86-64 and aarch64)	No. It starts the command and checks nothing	No. `ssg init` skips it

On Windows, ssg init does not compile the C hooks. Windows has no LD_PRELOAD equivalent.

Limits

The .agents/hooks.json hook sees only the tool calls that Antigravity sends to it. SigmaShake does not control which calls Antigravity sends. This page does not verify whether Antigravity sends calls from every agent context, such as a subagent or the browser agent.
The MCP path and the user rules file depend on the model. A model that does not call ssg_evaluate is not governed on that path. The user rules text says to apply only its hard denials when MCP and the CLI are not available, and to allow other actions.
The Node.js hook and the Python hook allow a call when no enforcer answers at all (no daemon and no ssg eval output). An enforcer that answers with an unreadable reply makes them deny the call.
The C hooks check open and openat only. They do not check other calls, such as network connections or deleting a file. They skip paths that contain .so, .dylib, /dev/, /proc/ or /sys/, and paths inside the .sigmashake directory or the ssg binary itself. A process that does not load the library is not covered.
On macOS, the system removes DYLD_INSERT_LIBRARIES when it starts a hardened-runtime binary or a binary that System Integrity Protection (SIP) protects, for example a binary in /bin or /usr/bin. The libssg file-open hook does not load into those processes. The PreToolUse hook and the MCP server still apply.
ssg-seccomp filters openat on x86-64 and aarch64 Linux. On macOS, and on Linux with any other CPU architecture, it only starts the command and checks nothing. On Linux it prints a warning in that case. On a supported architecture, the filter kills a process that makes a call through a foreign syscall ABI, such as a 32-bit compat call.
The C hooks and the runtime hooks work only in a process that you start with the right environment. See Start Antigravity with the hooks.
Network access is governed only through rule evaluation on the mapped tools read_url_content, search_web and browser_subagent. SigmaShake does not set an Antigravity network sandbox.
The C hook fails closed: if it cannot ask ssg, it blocks the open. The ssg hook antigravity hook also fails closed: an error, a bad input or a timeout returns deny.

Prerequisites

The ssg binary on your PATH. See Getting Started.
A signed-in ssg with an active SigmaShake subscription. The ssg binary is free to download and install. Governance is a paid surface. Evaluation fails closed without an active subscription: tool calls are not silently allowed. See Signing In.
On macOS and Linux: gcc on PATH. ssg init --client=antigravity compiles libssg and ssg-seccomp with it. Without gcc, an explicit install exits with an error. See Troubleshooting.

Quick setup

Run the command from your project directory.

ssg init --client=antigravity

To see the plan first, add --dry-run. In CI or another non-interactive shell, add --accept-terms.

When the install ends, ssg prints the launch command and three manual steps.

Copy .sigmashake/antigravity-rules.md into your Antigravity user rules.
Restart Antigravity to load the MCP server.
Optional: run ssg daemon for lower evaluation latency.

Start Antigravity with the hooks

The C hooks and the runtime hooks load only into a process that starts with the right environment. On macOS and Linux, when both C hooks compile, ssg prints a launch command like this one. The paths depend on your data directory. antigravity-agent-command is a placeholder for the command that starts your Antigravity agent.

LD_PRELOAD="$HOME/.sigmashake/hooks/hooks/libssg.so" \
NODE_OPTIONS="--require $HOME/.sigmashake/hooks/hooks/ssg-node-hook.cjs" \
PYTHONPATH="$HOME/.sigmashake/hooks/hooks/python:${PYTHONPATH}" \
SHELL=$HOME/.sigmashake/hooks/bin/bash \
$HOME/.sigmashake/hooks/bin/ssg-seccomp antigravity-agent-command

On macOS, the variable is DYLD_INSERT_LIBRARIES and the library is libssg.dylib. On Windows, ssg prints a launch command with NODE_OPTIONS, PYTHONPATH and SHELL only (the SHELL value is bash.cmd).

Use the command that ssg init prints on your machine. It has the exact paths.

What ssg init writes

Shared files in `~/.sigmashake/hooks/`

The default root is ~/.sigmashake/hooks. The SSG_HOOKS_DIR environment variable replaces it. Every file below is under this root.

File	OS	Purpose
`bin/bash`	macOS, Linux	Shell wrapper. Point `SHELL` at it
`bin/bash.cmd` and `bin/bash.ps1`	Windows	Shell wrapper launcher and engine
`hooks/ssg-node-hook.cjs`	all	Node.js hook. Load it with `NODE_OPTIONS="--require ..."`
`hooks/python/sitecustomize.py`	all	Python hook. Add its directory to `PYTHONPATH`
`hooks/src/libssg.c`	all	C source of the file-open library. `ssg` writes it on every OS, but compiles it on macOS and Linux only
`hooks/src/ssg-seccomp.c`	all	C source of the seccomp wrapper. Same rule
`hooks/libssg.so`	Linux	Compiled library
`hooks/libssg.dylib`	macOS	Compiled library
`bin/ssg-seccomp`	macOS, Linux	Compiled wrapper

The ssg binary path and the .sigmashake directory path are written into the C source when ssg init runs. The C hook uses them to skip ssg's own files.

The Node.js hook, the Python hook, and the shell wrapper are shared with the Pi and Aider adapters. One install serves every project.

Project files

File	Purpose
`.sigmashake/rules/`	Rules directory. `ssg init` makes sure it exists
`.sigmashake/antigravity-rules.md`	User rules text. You paste it into Antigravity
`.agents/hooks.json`	The `ssg-governance` hook entry

`.agents/hooks.json`

ssg init merges one named entry, ssg-governance, into .agents/hooks.json in your project. It does not overwrite other hooks in the file. A second ssg init replaces only the ssg-governance entry.

{
  "ssg-governance": {
    "PreToolUse": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "'/path/to/ssg' hook antigravity",
            "timeout": 30
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "'/path/to/ssg' hook post-eval --client=antigravity",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

/path/to/ssg is the resolved absolute path of the ssg binary. On Windows, ssg double-quotes the path instead of single-quoting it.
If the existing entry already uses the portable command "$HOME/.sigmashake/bin/ssg" and that file is executable, ssg init keeps the portable form. On Windows it writes the absolute path.
The PreToolUse hook returns one JSON verdict on stdout: allow, deny or ask.
The PostToolUse hook records that a tool call finished. It never evaluates a rule again and it always exits 0.

How rule decisions become hook verdicts

SSG decision	Antigravity verdict
`allow`, `log`, `shadow`	`allow`
`block`	`deny`
`force`	`deny` (the original call is never approved)
`ask`	`ask`, unless the dashboard answers first (see below)
Any other value, an error, bad input, an unreachable daemon, or a timeout	`deny`

ssg hook antigravity does not honor SSG_HOOK_FAIL_OPEN.

For an ask decision, the hook first waits for an answer in the SSG dashboard. The default wait is 15 seconds. Start the dashboard with ssg serve. If the dashboard does not answer, the hook returns ask to Antigravity. The hook stops its own wait at 20 seconds and returns deny, before the 30-second timeout in hooks.json.

MCP config

ssg init merges an ssg-governance entry under mcpServers in this file:

~/.gemini/config/mcp_config.json

ssg init creates the directory if it does not exist. Other MCP servers in the file stay unchanged. On Windows, ~ is your user profile directory.

{
  "mcpServers": {
    "ssg-governance": {
      "command": "/path/to/ssg",
      "args": ["mcp-server", "--client=antigravity"],
      "env": { "SSG_CLIENT": "antigravity" }
    }
  }
}

If you choose MCP tool groups with --mcp-tools, ssg init adds --tools=<groups> to args. If the MCP toggle is off, ssg init removes the ssg-governance entry and writes none.

Restart Antigravity after ssg init. It loads MCP servers at startup.

User rules file

.sigmashake/antigravity-rules.md holds a <RULE[SSG-GOVERNANCE]> block. It tells the model to:

call the ssg_evaluate MCP tool before a tool call that changes state, reads secrets, runs code, or makes a network request;
fall back to echo '{"tool":"<name>","input":{...}}' | SSG_CLIENT=antigravity ssg eval when MCP is not available;
refuse on block, ask you on ask, and substitute the action on force;
always apply a list of hard denials, such as destructive commands and reads of .env files, even when MCP and the CLI are not available.

ssg init does not load this file into Antigravity. You copy the block into your Antigravity user rules. Run ssg init --client=antigravity again to regenerate the file after a rule change.

Tool capability mapping

The ssg hook antigravity hook converts the arguments of each Antigravity tool into the input fields that rules read. The same mapping is in the user rules file.

Antigravity tool	SSG capability	SSG `input` fields (from Antigravity argument)
`run_command`	`execute`	`command` (`CommandLine`)
`send_command_input`	`execute`	`command` (`Input`)
`write_to_file`	`write`	`path` (`TargetFile`), `content` (`CodeContent`)
`replace_file_content`	`write`	`path` (`TargetFile`)
`multi_replace_file_content`	`write`	`path` (`TargetFile`)
`view_file`	`read`	`path` (`AbsolutePath`)
`list_dir`	`search`	`path` (`DirectoryPath`)
`grep_search`	`search`	`path` (`SearchPath`), `command` (`Query`)
`read_url_content`	`network`	`path` (`Url`)
`search_web`	`network`	`command` (`query`)
`browser_subagent`	`agent`	`command` (`Task`)
`generate_image`	none listed in Client Adapters	`command` (`Prompt`)

A tool that is not in this table reaches the rule engine with its arguments unchanged. The hook sends the Antigravity tool name as the tool value.

Rules target capabilities. See Fields and Rule Syntax.

Verify it works

ssg status
ssg doctor

Send a test call to the hook. The command must print exactly one JSON object with a decision of allow, deny or ask.

echo '{"toolCall":{"name":"run_command","args":{"CommandLine":"echo test"}}}' | ssg hook antigravity

Check that the files exist:

cat .agents/hooks.json
cat ~/.gemini/config/mcp_config.json
ls .sigmashake/antigravity-rules.md

Then run a command in Antigravity that one of your rules blocks, and list the blocked actions:

ssg blocked

Uninstall

Run the command from the project directory that you set up.

ssg uninstall --dry-run   # preview
ssg uninstall

ssg uninstall is the factory reset of ssg. It also stops the daemon and strips the hooks of other clients. The --keep-data flag leaves ~/.sigmashake/ in place. The Antigravity part of the reset removes these items:

the shell wrapper, the Node.js hook, and the Python hook (and the same files in the older per-project .ssg/ directory);
libssg.so or libssg.dylib, and ssg-seccomp;
.sigmashake/antigravity-rules.md;
the ssg-governance entry in .agents/hooks.json. Other entries stay;
the ssg-governance entry in ~/.gemini/config/mcp_config.json. Other servers stay.

The Antigravity step of the reset does not remove the C source files in hooks/src/. It removes only the files in the list above. Without --keep-data, ssg uninstall also removes the ~/.sigmashake/ data directory in a later step, so the C source files go away with it when the hooks directory is inside that directory. With --keep-data, they stay. It does not remove the text that you pasted into your Antigravity user rules. Remove that text by hand.

Restart Antigravity after the uninstall.

Troubleshooting

`ssg init --client=antigravity` exits with an error about the C hook compile

On macOS and Linux, an explicit --client=antigravity install fails when gcc is missing or a compile fails. This is deliberate. ssg does not report an install when the file-open layer is not in place. Install a C compiler and run the command again. To get a partial install instead, run ssg init --client=all. That install still writes the runtime hooks, hooks.json, and the MCP entry, and it prints that file-open interception did not compile.

The hook does not run

Check that .agents/hooks.json exists in the workspace root and has the ssg-governance entry. Run the hook by hand (see Verify it works). If the hook returns deny with "ssg evaluation unavailable", the daemon is not reachable or the evaluation failed. Run:

ssg status
ssg daemon

MCP tools are not visible in Antigravity

Check that ~/.gemini/config/mcp_config.json has the mcpServers.ssg-governance entry, and that the server starts:

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | ssg mcp-server --client=antigravity

Restart Antigravity. It loads MCP servers at startup.

File opens are not blocked

The C hooks load only into a process that starts with LD_PRELOAD (Linux) or DYLD_INSERT_LIBRARIES (macOS) set to the library. Start the agent with the command that ssg init printed. Windows has no C hook.

Every tool call is denied

The hook fails closed. Run ssg status and ssg doctor. Check that you are signed in and that the subscription is active. See Signing In.

`ask` decisions time out

Start the dashboard with ssg serve before you use ask rules. See Dashboard.

Client Adapters — Adapter reference for every client
MCP Server — MCP tool reference
Rule Syntax — Rule language reference
Writing Rules — Patterns and best practices
Dashboard — Approval and audit UI
OpenCode Integration — Another client with a plugin hook and MCP

What SSG governs and what it does not​

What the layers do​

Coverage by operating system​

Limits​

Prerequisites​

Quick setup​

Start Antigravity with the hooks​

What ssg init writes​

Shared files in ~/.sigmashake/hooks/​

Project files​

.agents/hooks.json​

How rule decisions become hook verdicts​

MCP config​

User rules file​

Tool capability mapping​

Verify it works​

Uninstall​

Troubleshooting​

ssg init --client=antigravity exits with an error about the C hook compile​

The hook does not run​

MCP tools are not visible in Antigravity​

File opens are not blocked​

Every tool call is denied​

ask decisions time out​

Related​