Current release update (Aug. 6): Reproduced unchanged on the current v0.1.54 public artifact (2a4f9cf). PR #261 carries the minimal fix plus network-free regressions for both the POSIX and native Windows hooks.
Stage
connect
Coding agent
OpenAI Codex
Coding agent version
Codex desktop; Monk plugin v0.1.54 (2a4f9cf)
Repro steps
The shipped Antigravity manifest gives both ensure-monk-agent PreInvocation hooks a 10-second timeout. Each hook first makes a readiness request with a two-second timeout, then, after starting the companion, performs ten iterations containing a one-second sleep plus another two-second readiness request.
I added network-free regressions that run the exact shipped POSIX and native PowerShell hooks with:
- isolated home and agent data directories;
- a live fake companion so the early-exit branch does not shorten the loop;
- readiness probes that take two seconds and return unavailable; and
- a supervisor using the timeout read from
.antigravity-plugin/hooks.json.
On pristine v0.1.54 the POSIX regression fails:
FAIL: Antigravity's declared 10-second timeout kills the cold-start hook before it emits readiness JSON
The supervisor returns 124 and stdout is empty. The hook's intended did not become ready injectSteps payload is never emitted. The PowerShell hook has the same ten-iteration structure (Start-Sleep -Seconds 1 plus Invoke-WebRequest -TimeoutSec 2) under the same manifest timeout.
Expected behavior
The cold-start hook should use a wall-clock readiness deadline and complete with either the healthy-start payload or its actionable not-ready payload before Antigravity's declared host timeout.
Actual behavior
The retry count is treated as elapsed seconds even though every iteration also performs a bounded network request. Even immediate connection refusal leaves no margin because the ten sleeps consume the full 10-second budget. A loopback listener that accepts but does not answer can make the path take roughly 32 seconds including the initial probe, so Antigravity terminates the hook without JSON and the invocation receives no diagnostic.
I validated a minimal fix locally and in PR #261:
- replace both ten-iteration loops with a ten-second wall-clock deadline; and
- raise the two Antigravity ensure-hook timeouts to 20 seconds, leaving margin for the initial and final bounded probes.
Both focused regressions then pass, the POSIX hook passes syntax validation, the PowerShell file parses with zero errors, and the manifest remains valid JSON.
Collision check
I searched all repository issues (open and closed, limit 500) for Antigravity, PreInvocation, ensure-monk-agent, timeout, readiness, and did not become ready.
#52 is the same defect class in the separate 180-second SessionStart launchers from v0.1.43. It was closed as fixed in v0.1.50 after those launchers adopted wall-clock deadlines. This report is the current Antigravity-only PreInvocation implementation introduced and shipped separately; the #52 fix did not cover it, and v0.1.54 still reproduces the host-timeout failure. Other search matches concern config registration, uninstall cleanup, port conflicts, or health verification rather than Antigravity killing this hook before stdout.
Severity (your guess)
major
A cold or unhealthy companion can silently consume the PreInvocation hook budget on every model invocation. The hook starts a background process and writes its PID, but Antigravity receives neither the success payload nor the intended recovery/log guidance.
OS
Windows 11. Git Bash exercises the exact shipped POSIX hook; native Windows PowerShell exercises the .ps1 hook. Both use isolated process and network fixtures.
monkd version
Not involved; the defect is in the local companion PreInvocation lifecycle.
Target cloud
None; network-free hook fixtures.
Integration
Monk plugin for Antigravity
Stage
connect
Coding agent
OpenAI Codex
Coding agent version
Codex desktop; Monk plugin v0.1.54 (
2a4f9cf)Repro steps
The shipped Antigravity manifest gives both
ensure-monk-agentPreInvocation hooks a 10-second timeout. Each hook first makes a readiness request with a two-second timeout, then, after starting the companion, performs ten iterations containing a one-second sleep plus another two-second readiness request.I added network-free regressions that run the exact shipped POSIX and native PowerShell hooks with:
.antigravity-plugin/hooks.json.On pristine v0.1.54 the POSIX regression fails:
The supervisor returns 124 and stdout is empty. The hook's intended
did not become readyinjectStepspayload is never emitted. The PowerShell hook has the same ten-iteration structure (Start-Sleep -Seconds 1plusInvoke-WebRequest -TimeoutSec 2) under the same manifest timeout.Expected behavior
The cold-start hook should use a wall-clock readiness deadline and complete with either the healthy-start payload or its actionable not-ready payload before Antigravity's declared host timeout.
Actual behavior
The retry count is treated as elapsed seconds even though every iteration also performs a bounded network request. Even immediate connection refusal leaves no margin because the ten sleeps consume the full 10-second budget. A loopback listener that accepts but does not answer can make the path take roughly 32 seconds including the initial probe, so Antigravity terminates the hook without JSON and the invocation receives no diagnostic.
I validated a minimal fix locally and in PR #261:
Both focused regressions then pass, the POSIX hook passes syntax validation, the PowerShell file parses with zero errors, and the manifest remains valid JSON.
Collision check
I searched all repository issues (open and closed, limit 500) for
Antigravity,PreInvocation,ensure-monk-agent,timeout,readiness, anddid not become ready.#52 is the same defect class in the separate 180-second SessionStart launchers from v0.1.43. It was closed as fixed in v0.1.50 after those launchers adopted wall-clock deadlines. This report is the current Antigravity-only PreInvocation implementation introduced and shipped separately; the #52 fix did not cover it, and v0.1.54 still reproduces the host-timeout failure. Other search matches concern config registration, uninstall cleanup, port conflicts, or health verification rather than Antigravity killing this hook before stdout.
Severity (your guess)
major
A cold or unhealthy companion can silently consume the PreInvocation hook budget on every model invocation. The hook starts a background process and writes its PID, but Antigravity receives neither the success payload nor the intended recovery/log guidance.
OS
Windows 11. Git Bash exercises the exact shipped POSIX hook; native Windows PowerShell exercises the
.ps1hook. Both use isolated process and network fixtures.monkd version
Not involved; the defect is in the local companion PreInvocation lifecycle.
Target cloud
None; network-free hook fixtures.
Integration
Monk plugin for Antigravity