[Bug]: Custom Antigravity binary fails with wrapper scripts (.cmd/.bat) due to rigid localharness_external sibling check #12752

Activity

1. juliusmarminge commented on Sep 20, 2026

   

   juliusmarminge

   on Sep 20, 2026

   Member

   More actions

   Triage

   Confirmed against shipping v0.0.42 and current main. This is a real Windows custom Antigravity binary limitation, not a desktop-only bug, not a missing managed install, and not the Linux aarch64 custom-path tickets.

   The filed copy matches the server:

   • Not found — The custom Antigravity executable or its localharness_external sibling is missing or not executable.
   • Unavailable — Antigravity could not complete its local health check.

   Area is apps/server, not apps/desktop. Desktop only hosts the server that resolves and spawns the ACP pair.

   What the code does

   1. Custom binaryPath is a same-directory pair. There is no managed-harness fallback.

   Resolution lives in apps/server/src/provider/AntigravityInstallation.ts (fromExternal — there is no resolveSiblingExternalBinary). For an override it:

   1. Requires the custom path to be a real file (agy-wrapper.cmd counts as a file on Windows; execute-bit is not checked).
   2. Requires localharness_external.exe in that same directory.
   3. Otherwise fails immediately with the sibling error above. It does not fall back to the managed tool dir or to PATH.

   That pairing is intentional. Docs say to extract agy_acp_server and localharness_external into the same directory, at the same version. Tests assert an override without a sibling fails and does not fall back (honors explicit paths and reports invalid overrides without falling back).

   A placeholder localharness_external.cmd still fails resolve: the Windows harness name is localharness_external.exe. A copied real .exe next to the wrapper does pass resolve.

   2. Passing resolve and then hanging is the Windows .cmd ACP spawn path.

   Spawn is buildAntigravityAcpSpawnInput → AcpSessionRuntime → resolveSpawnCommand (packages/shared/src/shell.ts). On Windows, .cmd / .bat is routed with shell: true (cmd.exe /c). ACP is JSON-RPC over stdin/stdout; that shell hop commonly breaks or stalls the handshake.

   On v0.0.42 the provider probe still spawned, so this showed up as the generic health-check line. On main (#12008) the probe is disk-only and does not spawn. Symptom shift:

   Setup	v0.0.42	main
   Wrapper, no localharness_external.exe sibling	Sibling resolve error	Same
   Wrapper + copied/real .exe sibling	Health-check hang / generic unavailable	Disk probe can pass; session / sign-in still spawn and can hang

   3. Mixing a custom wrapper with the managed harness is not free.

   ANTIGRAVITY_HARNESS_PATH is injected from the resolved sibling. Falling back to the managed localharness_external when the wrapper is a different release can fail or hang worse than the current hard reject. Same-version pairing is the constraint, not just “file lives next door.”

   Related, not duplicates

   Work	Why it does not close this
   #12477 / #12490	Linux aarch64 custom/managed health check. Different host and cause.
   #12722	Expands ~/ and directory custom paths so a CDN extract of the real pair resolves. Does not accept wrappers or a missing sibling.
   #10932	agy CLI vs ACP runtime. This path already found a custom file.
   #12008	Probe no longer spawns. Changes where the .cmd hang appears; does not fix resolve or spawn.

   Unique combination: Windows + custom wrapper / .cmd path + rigid sibling check (and ACP stdio through cmd.exe once a sibling exists).

   Workaround (supported)

   Point Binary path at the raw unpacked agy_acp_server.exe in the directory that also contains localharness_external.exe (managed install, or a same-version manual extract). Do not point it at a .cmd / .bat wrapper or at agy.

   Env / temp isolation the wrapper was meant to provide is already applied by T3 (prepareAntigravityProfile, per-process TMPDIR). Prefer that over an intermediate launcher.

   Suggested fix

   Keep the same-directory pair as the documented custom install.

   1. Bug: ACP spawn on Windows must keep stdin/stdout when binaryPath is .cmd / .bat (unwrap to a real .exe, or avoid cmd.exe /c for this protocol). Claude already unwraps npm .cmd shims for a similar reason.
   2. Enhancement (optional, careful): if the custom file exists but has no harness sibling, fall back to the same-version managed localharness_external only. Do not pair a wrapper with a different harness.

   No extra logs needed to place this. A redacted server.trace.ndjson around AntigravityInstallation.resolve / AcpSessionRuntime spawn would still help confirm the .cmd hang on a real session start.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 20, 2026
3. cestercian commented on Sep 21, 2026

   

   cestercian

   on Sep 21, 2026

   Contributor

   More actions

   I'd like to take this — I'll prepare a focused fix and regression coverage.