Mneme HQ + Google Antigravity

Status: shipped, merged, tested

The adapter merged on August 24, 2026 (PR #316) and lives at mneme/integrations/antigravity/adapter.py. It carries 31 focused tests covering translation, gate verdicts, fail-open semantics, modes, no-opinion paths, invocation contract, and identity pins. Full suite at merge: 780 passed / 5 skipped versus an attached-equivalent baseline of 749/5 — +31 new tests, zero regressions.

How it works: a translation layer, nothing more

The adapter implements no governance semantics of its own. Materialization, introduced-delta selection (ADR-018), memory discovery, mode resolution, verdict parsing, and reason formatting are imported from the existing Claude Code hook module — the same enforcement path, behind an Antigravity-specific normalizer:

Antigravity PreToolUse payload
   ↓
Normalizer: write_to_file / replace_file_content /
            multi_replace_file_content
   ↓
Canonical Write / Edit / MultiEdit ToolEvent
   ↓
Introduced-content materialization + mneme check
   ↓
{"decision": "deny", "reason": ...}  or  {}  (no opinion)

Read-only tools never reach the gate. If mneme check changes, this adapter follows automatically — it is not a second enforcement implementation.

Setup

Create .agents/hooks.json inside a governed project (one with a committed .mneme/project_memory.json):

{
  "mneme": {
    "PreToolUse": [
      {
        "matcher": "write_to_file|replace_file_content|multi_replace_file_content",
        "hooks": [
          {
            "type": "command",
            "command": "python -m mneme.integrations.antigravity",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

• The command needs mneme-hq importable — point PYTHONPATH at your install or invoke an installed console wrapper.
• Enforcement mode follows the shared resolution: MNEME_HOOK_MODE environment variable, then "strict".
• No DecisionRetriever or MemoryStore dependency exists in the adapter; retrieval remains a separate layer (AST-pinned by identity tests, mirroring the Agent SDK convention).

Allow/deny semantics: deny is the only active decision

Antigravity’s response contract differs from Claude Code’s in one important way: emitting "allow" auto-grants the tool call, bypassing the normal permission flow. The adapter therefore never emits it:

Verified runtime contract (Antigravity IDE 2.8.1)

• hooks.json lives in .agents/; PreToolUse fires before execution with the full proposed content
• stdin JSON envelope: {toolCall: {name, args}, workspacePaths, ...} → stdout JSON decision
• A live deny prevented a filesystem mutation (target verified absent); a compliant mutation landed unchanged
• Malformed hook output blocks the call — verified live, which is why every adapter path emits valid JSON
• Layer separation confirmed: in PASS cases Antigravity’s own permission layer permitted the same tool/workspace; only Mneme blocked in the FAIL case

Limitations

• Tested version: Antigravity IDE 2.8.1. Newer IDE releases may change the hooks envelope and require re-validation.
• Covered tools: the three file-mutation tools above. Shell commands are not covered — their mutations cannot be reconstructed reliably enough to check deterministically.
• No guidance surface: the adapter does no context injection and does not retrieve decisions into the model’s context. Retrieval/enforcement separation is deliberate.
• No MCP, no SDK integration, no generic adapter framework — out of scope by design in PR #316.

Evidence

• PR #316 — implementation, response policy, and test record
• docs/integrations/antigravity.md — architecture and configuration reference
• tests/integrations/antigravity/ — gate, parser, and identity test suites

FAQ