Gap
#202's hardware verification turned up a second auto-approval path in agy 1.1.7 that the parser does not read. Headless mode names it in its own error text:
a tool required the "command" permission that headless mode cannot prompt for … Add an allow-rule under permissions.allow in settings.json (e.g. command(<target>))
Verified: {"permissions":{"allow":["command(echo)"]}} in ~/.gemini/antigravity-cli/settings.json auto-approved a call that is otherwise refused. This is the same class as the toolPermission finding the parser already emits, but per-command rather than global — and a broad entry (command(*), or one covering a destructive prefix) is a standing approval with no prompt.
Also from #202: a stale contract note
toolPermission still governs behaviour — always-proceed auto-approved on 1.1.7 — so the existing detection stays. But the parser's documented premise no longer holds: writing an unrecognized value produced no rejection and no rewrite, leaving the file byte-identical. The #158/PR#167 note that agy rejects unknown values and falls back to request-review should be corrected, and the effect of an unrecognized value is now unverified rather than known-safe. That also means the probing method used in #158 can no longer enumerate the accepted values, so the reported 4th value strict stays unconfirmed.
Work
Scope
Mechanism only. Parser + reason reuse (AutoApprovalEnabled fits) + tests.
Gap
#202's hardware verification turned up a second auto-approval path in agy 1.1.7 that the parser does not read. Headless mode names it in its own error text:
Verified:
{"permissions":{"allow":["command(echo)"]}}in~/.gemini/antigravity-cli/settings.jsonauto-approved a call that is otherwise refused. This is the same class as thetoolPermissionfinding the parser already emits, but per-command rather than global — and a broad entry (command(*), or one covering a destructive prefix) is a standing approval with no prompt.Also from #202: a stale contract note
toolPermissionstill governs behaviour —always-proceedauto-approved on 1.1.7 — so the existing detection stays. But the parser's documented premise no longer holds: writing an unrecognized value produced no rejection and no rewrite, leaving the file byte-identical. The #158/PR#167 note that agy rejects unknown values and falls back torequest-reviewshould be corrected, and the effect of an unrecognized value is now unverified rather than known-safe. That also means the probing method used in #158 can no longer enumerate the accepted values, so the reported 4th valuestrictstays unconfirmed.Work
permissions.allowfrom~/.gemini/antigravity-cli/settings.json(and the per-repo settings file, once Re-verify Antigravity hook contract on agy 1.1.x (revisit #112 static-posture-only default) #202's open question about which path 1.1.x reads is settled).command(echo)is scoped;command(*)is not. The Claude Code predicate from ai-guard: refresh Claude Code surface — auto mode, autoMode rules block, non-command hooks, loop.md #199 is a reasonable starting point but the syntax differs, so it needs its own rule rather than a shared one — the same reasoning as issue ai_guard: align broad-allow heuristic between gemini.rs and claude_code.rs #30.toolPermissiondoc comment inparser/antigravity.rs, which currently states the validator rejects unknown values.Scope
Mechanism only. Parser + reason reuse (
AutoApprovalEnabledfits) + tests.