I can add an independent, controlled reproduction of this. Short version: on current public builds, hooks execute in the agy CLI only. The IDE and the Antigravity 2.0 desktop app do not execute PreToolUse hooks at all — under any documented registration route, and it is not a manifest error.
Environment (the diagnostics requested upthread)
| Component |
Version |
| Antigravity IDE |
2.1.1 (VS Code OSS 1.107.0, commit e0b7a2b, build 2026-06-17) — latest on the public changelog |
| Antigravity 2.0 desktop |
2.5.0 (956667124) |
agy CLI |
1.1.10 |
| OS |
macOS, Apple Silicon (Darwin 25.5.0) |
| Node |
v26.4.0 |
| Model |
Install defaults, unchanged. The CLI control runs captured "modelName": "gemini-3.6-flash-high" in the hook payload |
What we registered
A single probe hook — a shell script that appends its stdin and environment to a log file and prints {"decision":"allow"} with exit 0 — registered simultaneously through every documented route:
<workspace>/.agents/hooks.json (workspace root exactly matching the opened folder, folder trusted)~/.gemini/config/hooks.json (global)- Plugin route:
~/.gemini/config/plugins/denied-probe/ with plugin.json containing only name/description (no invented "hooks" key — this differs from the OP’s setup and rules out the manifest-error explanation) and hooks.json at the plugin root
hooks.json used the documented named-group schema:
{
"denied-step0-probe": {
"PreToolUse": [
{
"matcher": "*",
"hooks": [
{ "type": "command", "command": "/absolute/path/to/probe.sh", "timeout": 10 }
]
}
]
}
}
Full apps were restarted after installation.
Results
| Surface |
Result |
agy CLI (control) |
Fires on every tool call, from the global registration. Full payload arrives on stdin (toolCall.name/args, conversationId, transcriptPath, modelName, …). {"decision":"deny"} hard-blocks with the reason surfaced. |
| Antigravity IDE 2.1.1 |
Zero hook invocations. run_command (pwd, echo hello) executed normally with no log entry, no error, no console message — silent non-engagement. Retested with file read/write tools on a later day to rule out tool-type-scoped wiring: also zero invocations. |
| Antigravity 2.0 desktop 2.5.0 |
Zero hook invocations, same conditions. |
The CLI control fired correctly under the identical global registration the entire time, which rules out a probe-script, permissions, or schema problem. There was no console/output-panel error in either GUI app — the hooks are simply never consulted.
Why this looks like a product gap, not user error
- The bundled offline docs that ship inside the apps (
builtin/skills/agy-customizations/docs/hooks.md, regenerated by the current builds) document the hook payload’s transcriptPath as surface-specific — explicitly listing antigravity-cli/ (CLI), antigravity/ (2.0), and antigravity-ide/ (IDE) directory variants. So the documentation clearly intends hooks to run on all three surfaces.
- The same bundled docs name
.agents/ and ~/.gemini/config/ as the customization roots — exactly what we registered.
- Every hook-related fix on the public changelog (1.1.7 “disabled plugins still running their hooks”, 1.1.9 stop-hook and
PostToolUse matcher fixes, 1.1.10 hook ordering) is on the CLI track. No IDE- or 2.0-track entry has ever mentioned hooks.
One piece of conflicting public evidence: a 2026-07-16 blog post by Mete Atamel shows captured hook payloads whose paths sit under ~/.gemini/antigravity-ide/brain/…, i.e. apparently from the IDE. No version is stated there, and no public IDE build newer than 2.1.1 exists — so if that capture is genuine, it suggests GUI hook execution exists in a build that hasn’t shipped publicly.
Question for the Antigravity team: is PreToolUse/PostToolUse execution in the IDE and the 2.0 desktop app (a) implemented but gated on something undocumented, (b) shipping in an upcoming release, or (c) currently CLI-only by design? Any of those answers would be useful — several of us are building governance/safety tooling on the hook contract, and right now the docs say one thing and the shipped GUI builds do another.
Happy to provide the probe script, full logs, or a screen recording if that helps triage.