Antigravity reviewer can never deliver a result: agy print mode auto-denies the MCP call that IS the result channel #487

The unattended Antigravity reviewer (AI-1414, shipped in #479) is end-to-end non-functional. It launches, reads its context, reasons correctly — and then cannot deliver, so every round hangs until timeout.

Found by the first live certification run, on a purpose-built isolated daemon. Every unit test in the suite passes.

Evidence

agy's own log, inside the reviewer's per-launch HOME:

Print mode: soft-denying tool confirmation "McpTool" at step 2
Tool confirmation for conversation 90f7157a-… step 2 (type=*Step_McpTool approved=false)
permission check failed for mcp "kcap-flow-result/submit_review_result":
    user denied permission for mcp

Conversation transcript stops at USER_INPUT DONE → PLANNER_RESPONSE DONE, with no TOOL_CALL step. The turn child exits; the flow sits at timeout waiting for participant result with the participant still running.

Everything up to delivery is correct: the isolated home is created, mcp_config.json carries kcap-flow-result with the right KCAP_FLOW_AGENT_ID, the daemon advertises the vendor, and the launch reports reviewFlow=True.

Cause

agy -p (print mode) auto-denies MCP tool confirmations, because headless mode has no human to approve them. The reviewer's result channel is an MCP tool (kcap-flow-result/submit_review_result), so the one call the round depends on is the one print mode refuses.

The reviewer deliberately does not pass --dangerously-skip-permissions — that decision is correct and measured (the flag is the entire read boundary; a reviewer only reads). But nothing accounted for the result channel needing a permission agy will not grant unattended.

Fix — narrow, and it keeps the boundary

agy names the remedy itself (string in the shipped binary):

… required the … that headless mode cannot prompt for, so … auto-denied. Add an allow-rule under permissions.allow in settings.json (e.g. …)

So: AntigravityReviewerHome.Create should write a permissions.allow rule into the per-launch home's settings.json granting exactly kcap-flow-result/submit_review_result and nothing else.

That is strictly better than widening the launch posture — it grants the single tool the reviewer must call, leaving the read boundary intact. Exact rule syntax needs verifying against agy before writing it.

The test gap this exposes

The suite proves at length what the reviewer cannot do — real-process containment, typed denials, an isolated home verified by lsof and filesystem observation — and never asserted that it can still do its job. Denial coverage and function coverage are independent, and a complete denial suite is perfectly consistent with a feature that never works.

This is the same shape as the Copilot borrowed-reviewer sandbox (AI-1797), where the HOME redirect that closed ~/.copilot also cut kcap mcp flow-result off from its credential. Second vendor, same lesson: closing an ambient path closes it for your own helpers too.

Fix should land with a test that asserts delivery, not merely containment.

Related: AI-1414, AI-1797, kcap-cli #479.