[Bug]: Antigravity custom runtime fails local health check on Linux ARM64 (aarch64) #12477

Activity

1. sunjay-dev

   added

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

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 18, 2026
2. juliusmarminge commented on Sep 18, 2026

   

   juliusmarminge

   on Sep 18, 2026

   Member

   More actions

   Triage

   Confirmed against shipping v0.0.42 and current main. This is a real Antigravity setup failure on Linux aarch64, not a PATH/agy miss and not the Windows Google sign-in or 15s-timeout bugs.

   Screenshots match the filed copy:

   • Environment larger-instance-2-0 (remote Linux host)
   • Runtime Installed. + “Uses the custom binary path below.”
   • Binary path under ~/.t3/tools/antigravity… (UI-truncated)
   • Provider: Unavailable — Antigravity could not complete its local health check.
   • Google account: Google sign-in failed. Start sign-in again.

   No server log / server.trace.ndjson was attached, so the exact child-process error is still hidden. The UI pair (Installed + generic health-check line) is still enough to place the failure.

   What the code does

   1. “Installed” here means the custom ACP pair resolved on disk, not that the agent answered initialize.

   Resolution (apps/server/src/provider/AntigravityInstallation.ts fromExternal):

   1. Binary path must be the ACP file (agy_acp_server.par on Linux), executable
   2. sibling localharness_external in the same directory, also executable
   3. else managed runtime, else PATH

   A directory-only path (…/tools/antigravity) fails resolve with “The custom Antigravity executable or its localharness_external sibling is missing or not executable.” That path sets installed: false and does not produce the screenshot. So the override resolved to a real pair.

   On v0.0.42 the health probe then spawns that pair and calls ACP initialize (AntigravityDriver → runtime.initialize(), 90s timeout). installed stays true unless the error looks like a missing binary. Any other spawn / profile / transport failure becomes the generic line in the screenshot:

   Antigravity could not complete its local health check.

   That is not the timeout string (“did not respond … within 90 seconds”). The process was found and then failed quickly.

   2. v0.0.42 already ships an official linux-arm64 runtime. Manual CDN + custom path is optional.

   Pinned asset in antigravityRelease.ts (same in 0.0.42 and main):

   https://dl.google.com/agy-extensions/releases/linux/agy-acp-server-agy_acp_server_1.1.1-linux-arm64.zip

   In-app Install Antigravity on this host should fetch that zip. Custom path is valid only when it points at agy_acp_server.par with localharness_external beside it. agy is never a candidate (#12067).

   3. Google sign-in on this screenshot is the same spawn path, not the Windows browser-handoff bug.

   Sign-in also runs prepareAntigravityProfile + ACP start. AntigravityAuth.safeAuthFailure falls back to “Google sign-in failed. Start sign-in again.” for unrecognized errors. The card shows that fallback with Retry, not “Waiting for Google sign-in” / Open sign-in page. Browser-never-opens (#9624 / #12473) does not match.

   On v0.0.42, profile setup uses process.execPath as the Node helper that suppresses the agent’s browser (antigravityAuthSupport.ts). On a standalone t3 binary (NodeSea, @t3code/t3-linux-arm64) that is the T3 executable, not Node. The preflight then fails with “Antigravity browser suppression could not be verified.” — an AcpTransportError that the health check and sign-in both swallow into the generic strings above. That is a strong fit for a remote aarch64 box named larger-instance-2-0. It is not proven without the trace; npx t3 / a real node on PATH would skip this particular failure.

   4. Two fixes landed after 0.0.42; they change the health-check symptom, not necessarily usability.

   Change	In 0.0.42?	Effect
   #12008 — probe is disk resolve only; per-process TMPDIR	no	Health check would report ready if the pair exists. Sessions and sign-in still spawn.
   #12033 — resolve real node for the browser helper	no	Standalone t3 no longer uses itself as Node. Missing Node surfaces “Antigravity sign-in requires Node.js…” instead of the generic health/sign-in lines.

   Both are in 0.0.43-nightly (main). Updating can clear the filed health-check line while sign-in still fails if the .par cannot exec or Node is still missing.

   Related, not duplicates

   Work	Why it does not close this
   #12067	agy on PATH / ~/.local/bin. This host already resolved a custom ACP pair; Runtime says Installed.
   #9624 / #12473	Windows: sign-in UI never opens a browser. This is Linux; sign-in never reached the waiting/URL phase.
   #11414	x86 no-AVX SIGILL during managed validate. This is aarch64 + custom path already marked Installed.
   #9432	Windows 15s probe vs ~45s cold start. 0.0.42 already uses 90s; the screenshot is the generic fail, not the timeout string.

   Unique combination: Linux aarch64 + manual Google CDN runtime + custom binary path + local health-check fail (generic copy, files resolved).

   What we still need from this machine

   On the remote environment (not the client laptop):

   uname -m
   file /path/to/agy_acp_server.par /path/to/localharness_external
   ls -l /path/to/agy_acp_server.par /path/to/localharness_external
   which node; node -v
   # how t3 was launched: standalone binary vs npx t3 / node

   And the redacted server.trace.ndjson / server log around AntigravityInstallation.resolve, prepareAntigravityProfile / browser suppression, and checkAntigravityProvider. Home paths and tokens redacted.

   Workaround (try in order)

   1. Binary path must be the file …/agy_acp_server.par, not the folder. localharness_external must sit next to it, both chmod +x. Use the linux-arm64 zip, not linux-x86_64.
   2. Prefer clearing Binary path and using Settings → Antigravity → Install Antigravity on this environment (same zip, hashed extract).
   3. Update the remote server off 0.0.42 to current 0.0.43-nightly (picks up fix(antigravity): stop health checks from filling the disk with _MEI folders #12008 and fix(server): resolve Node for standalone helper scripts #12033).
   4. On a standalone t3 host, install Node and put node on the server PATH, then retry sign-in.
   5. Confirm /tmp (0.0.42) or the profile temp dir has several GB free; the .par unpacks on the order of 1 GB per launch.

   Do not point Binary path at agy. Do not treat this as the Windows sign-in or no-AVX tickets.
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 18, 2026
4. sunjay-dev commented on Sep 18, 2026

   

   sunjay-dev

   on Sep 18, 2026

   Author

   More actions

   Here are the requested details from the remote environment larger-instance-2-0:

   Architecture:
   aarch64
   
   Node:
   which node -> /home/ubuntu/.nvm/versions/node/v24.17.0/bin/node
   node -v    -> v24.17.0
   
   T3:
   type -a t3 -> not found
   
   T3 Code is running as the standalone v0.0.42 binary through a systemd user service:
   
   [Service]
   Type=simple
   WorkingDirectory=%h
   Environment=T3CODE_HOME=/home/ubuntu/.t3
   Environment=T3_BOOT_SERVICE_UNIT=t3code.service
   ExecStart=/home/ubuntu/.t3/runtime/versions/0.0.42/t3 __service-launcher
   KillMode=mixed
   OOMPolicy=continue
   Restart=always
   RestartSec=5
   StandardOutput=append:/home/ubuntu/.t3/userdata/logs/boot-service.log
   StandardError=append:/home/ubuntu/.t3/userdata/logs/boot-service.log
   
   Disk space does not appear to be an issue:
   
   /dev/sda1  78G  41G  38G  52%  /
   
   The server trace is available at:
   
   /home/ubuntu/.t3/userdata/logs/server.trace.ndjson
   
   The Antigravity-related trace I found currently shows the post-install failure:
   
   AntigravityInstallation.resolve
   Failure:
   AntigravityInstallationError: Antigravity is not installed.
   Install it in this environment or set a custom executable path.
   
   AntigravityDriver.makeRuntime
   Failure:
   ProviderSetupError: Antigravity is not installed.
   Install it in this environment or set a custom executable path.
   
5. cursor

   added a commit that references this issue on Sep 20, 2026

   fix(server): resolve Antigravity custom paths on linux aarch64

   ...

   This issue will close once commit 83f8706 is merged into the 'main' branch.

   83f8706