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

[sunjay-dev]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Install the Antigravity runtime manually on a remote Linux server using the runtime package from Google's CDN.
2. Extract/install the runtime and verify that the runtime files are present on the server.
3. Open T3 Code and enable the Antigravity provider.
4. Configure Antigravity to use the custom binary/runtime path from the manual installation.
5. Attempt to use or authenticate the Antigravity provider.
6. Observe the provider status.

Expected behavior

T3 Code should detect and use the manually installed Antigravity runtime from the configured custom path.

If the runtime is valid and executable, the local health check should succeed and the Antigravity provider should become available.

Actual behavior

T3 Code reports the Antigravity provider as unavailable with:

"Antigravity could not complete its local health check."

The Runtime section shows the runtime as installed and indicates that the custom binary path is being used, but the provider remains unavailable.

Google sign-in also fails afterward, showing:

"Google sign-in failed. Start sign-in again."

Impact

Blocks work completely

Version or commit

v0.0.42

Environment

OS: Linux ARM64 (aarch64)

Logs or stack traces

Screenshots, recordings, or supporting files

Screenshot 2026-09-18 221605.png
Screenshot 2026-09-18 221554.png

Workaround

No workarround found

[juliusmarminge]

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.

[sunjay-dev]

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.