Antigravity + tman
The hook can allow, ask, or deny — but not rewrite. tman still decides whether the command runs; getting it supervised takes a shim or a denial the model can act on.
- vendor
- integration
- gates
- hook event
- PreToolUse
- config
- .agents/hooks.json or ~/.gemini/config/hooks.json
Antigravity's hook surface uses Claude-style event names — PreToolUse, PostToolUse, Stop — but the pre-tool contract is a gate, not a rewrite. The hook receives toolCall.name and toolCall.args and answers with a decision of allow, deny, ask, or force_ask. Tools like run_command can be permitted or blocked, not rewritten.
1. Install tman and adopt the project
Everything below assumes the binary is on your PATH and the repository has a .tman.kdl. That file is what scopes caps to this project, and it is also the signal several of the integrations test for before they do anything.
npm install -g @standardbeagle/tman # or the install.sh one-liner
cd your-project
tman init --shims --gitignoretman init writes a defaults block and an alias for each test or build command it can detect. Commands it cannot detect are left commented out rather than stubbed, so an alias you never filled in fails loudly instead of exiting 0 having run nothing.
2. Wire the hook
hooks.json lives in your customization directory — .agents/ in the workspace, or ~/.gemini/config/ globally. Note the enable flag: a hook block ships disabled and stays inert until you flip it, which is a common reason a correct config appears to do nothing.
{
"tman-supervision": {
"enabled": true,
"PreToolUse": [
{
"matcher": "run_command",
"hooks": [{ "type": "command", "command": "~/.config/tman-gate.sh" }]
}
]
}
}Turn the rewrite into an actionable denial
Because this hook cannot replace the command, the useful move is to refuse the unsupervised one and hand the model the supervised string to re-issue. tman already knows which commands deserve that and what the replacement should be, so the adapter is a few lines around tman hook pretooluse rather than a second copy of the classifier.
#!/usr/bin/env bash
# tman-gate.sh — deny an unsupervised test/build command, naming its supervised form.
set -euo pipefail
payload=$(cat)
# .toolCall.args.command // empty
command=$(jq -r '.toolCall.args.command // empty' <<<"$payload")
[ -n "$command" ] && [ "$command" != "null" ] || exit 0
verdict=$(jq -nc --arg c "$command" --arg d "$PWD" \
'{tool_name:"Bash", cwd:$d, tool_input:{command:$c}}' | tman hook pretooluse)
# tman stays silent on anything it will not supervise. So does this.
[ -n "$verdict" ] || exit 0
supervised=$(jq -r '.hookSpecificOutput.updatedInput.command // empty' <<<"$verdict")
[ -n "$supervised" ] || exit 0
jq -nc --arg s "$supervised" '{
permissionDecision: "deny",
permissionDecisionReason: ("Run it supervised instead: " + $s)
}'Confirm the payload field before you trust it. Hook payload shapes move between versions, and a
jqpath that no longer matches yields an empty command and a script that silently allows everything — a false green. Replace the script withcat > /tmp/hook-payload.jsonfor one run, read the file, then wire the real adapter against the field name you actually saw.
Antigravity's decision field is decision rather than permissionDecision, so change the adapter's final jq to emit {decision:"deny", reason: …}. Everything above it — reading the command, asking tman what the supervised form is — is unchanged.
3. Standing rules under .agents/
Antigravity reads AGENTS.md at the workspace root, with workspace rules under .agents/rules/ and global ones in ~/.gemini/GEMINI.md. A supervision rule belongs in the workspace copy, since the caps it references are the ones in this repository's .tman.kdl.
Tell the model, in AGENTS.md
Shims and hooks catch the mechanical cases. The remaining gap is the model deciding to do something clever — running the suite through a subshell, or with an inline environment assignment, both of which tman deliberately refuses to rewrite because prefixing a string it did not parse changes what runs. A standing instruction in AGENTS.md closes that gap:
## Running tests and builds
Run every test, build, lint, and typecheck command through tman — never bare.
Prefer the repo-root shims (`./test`, `./lint`) when they exist; they carry
this project's `.tman.kdl` caps. Otherwise prefix explicitly:
tman run -- <command>
Never widen the caps from the command line. Exit 124 is a timeout, 125 a stall,
126 a resource cull — report those, do not retry with looser limits.Verify it is actually on
A supervision integration that silently does nothing is worse than none, because it stops you looking. Two checks, both of which fail visibly:
# 1. the classifier agrees this command is worth supervising
echo '{"tool_name":"Bash","cwd":"'"$PWD"'","tool_input":{"command":"npm test"}}' \
| tman hook pretooluse
# 2. a real run shows up while it is in flight
tman run --name smoke -- sleep 30 &
tman listThe first prints a JSON object naming the rewritten command. Empty output means tman decided to stay out of the way — no .tman.kdl above cwd, a command it does not classify as test or build work, or a shell string it refused to parse. The second must list the run; if tman list is empty, nothing is being supervised.
Caps worth setting for agent-driven work
An agent re-runs the same command far more often than a human does, and it does it while you are not watching. That changes which caps earn their keep:
| cap | why it matters more under an agent |
|---|---|
--name | The agent will start the suite again before the last one finished. A dedup lock refuses the duplicate instead of running two copies against the same port or database. |
--max-parallel 2 | The default, and the right one for most repos. Excess runs queue on a slot file rather than stampeding your cores. |
--max-time | The only cap that bounds a run which is genuinely working but will never finish — a wait on a peer that never answers looks identical to healthy IO. |
--stall 30m | The built-in. A hang backstop, not a runtime budget: it should sit well above the longest quiet stretch your slowest command legitimately has. |
--max-mem | Opt-in, and worth it where a leak mode exists — worker pools, browser fleets, long-lived daemons. Off by default because builds are supposed to be greedy. |
Per-command starting points live in the tuning guides — one page per test and lint tool, with the reasoning behind each number rather than just the number.
Frequently asked
Can an Antigravity PreToolUse hook change the command that runs?
No. The hook receives toolCall.name and toolCall.args and returns a decision of allow, deny, ask, or force_ask. run_command can be permitted or blocked but not rewritten, so supervision comes from PATH shims plus a denial the model can act on.
My hooks.json looks right but nothing happens.
Check the `enabled` flag on the hook block — it defaults to false, so a correctly-shaped config stays inert until you set it true. Then confirm the file is in a directory Antigravity actually reads: `.agents/` in the workspace, or `~/.gemini/config/` globally.
Other agents
Sources
Vendor documentation this guide is written against — hook surfaces move, so check yours if something below does not match what you see.