[Bug]: Managed Antigravity install always fails on 16 KiB-page aarch64 kernels (Asahi, Raspberry Pi 5) and reports a disk-space error #34427

Before submitting

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

Related: #12490 (closed). A comment there identified this same page-size crash (comment), but the issue was closed after #12033 fixed a different cause (the Node helper preflight). The page-size failure is still present with runtime 1.4.5 on the latest nightly.

Area

apps/server

Steps to reproduce

1. Run T3 Code on an aarch64 Linux kernel with 16 KiB pages (getconf PAGESIZE → 16384). Examples: Asahi Linux on Apple Silicon, Raspberry Pi 5 with the default kernel.
2. Open Settings → Providers → Antigravity and choose Install (no custom binary path).
3. Wait for the 308 MB linux-arm64 download to finish.

Expected behavior

One of these:

• T3 Code detects the 16 KiB page size before the download and explains that Google's linux-arm64 Antigravity runtime needs a 4 KiB-page kernel. It then points to a supported remote environment or a custom executable, as it already does for unsupported platform-arch pairs ("Google does not publish an Antigravity runtime for …").
• At minimum, after validation fails, T3 shows the real reason instead of a generic one.

Actual behavior

The download and SHA-256 check succeed. The runtime then aborts on startup, so validation fails and nothing is installed. Retry installation repeats the 308 MB download and fails the same way every time.

Running the pinned binary by hand shows the cause. It is Google's build, not T3:

$ curl -sSfLO https://dl.google.com/agy-extensions/releases/linux/agy-acp-server-1.4.5-linux-arm64.zip
$ sha256sum agy-acp-server-1.4.5-linux-arm64.zip
7d64246633ae094f67e3bbcd2d679e89048f91346d5339313336e7483f40f056   # matches antigravityRelease.ts
$ unzip -q agy-acp-server-1.4.5-linux-arm64.zip && chmod +x agy_acp_server.par localharness_external
$ echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":1,"clientCapabilities":{}}}' | ./agy_acp_server.par
F1111 11:50:12.383176 page-size.cc:19] Check failed: sysconf(_SC_PAGE_SIZE) == kPageSize (16384 vs. 4096) Compile-time page size does not match runtime page size
    @ absl::log_internal::LogMessage::Flush()
    @ bamm2::internal::google_init_module_bamm2_init_verify_page_size()
    @ GoogleInitializer::RunInitializers()
    @ RealInitGoogle()
*** SIGABRT received ...

coredumpctl also shows the same SIGABRT from T3's own staging directory (~/.t3…/tools/antigravity-acp/linux-arm64/versions/.install-*/runtime/agy_acp_server.par) during earlier managed installs.

Separate but related: the Settings UI shows "Could not install Antigravity. Check free disk space and directory access, then try again." for any install failure that isn't an AntigravityInstallationError. On one attempt, the real cause in server.trace.ndjson was a transient ConnectTimeoutError to dl.google.com:443 (10 s). The disk-space wording sent me looking in the wrong place; the machine had 209 GB free. Surfacing the transport or timeout cause would help.

Impact

Blocks work completely

Version or commit

T3 Code Nightly 0.1.9-nightly.20261110.4465 (desktop AppImage); Antigravity ACP runtime 1.4.5 pinned in apps/server/src/provider/antigravityRelease.ts on main

Environment

Arch Linux ARM on Apple MacBook Pro (16-inch, M1 Max, 2021), kernel 7.1.12 (Asahi, 16 KiB pages), Node v24.21.0, provider: Antigravity

Logs or stack traces

# server.trace.ndjson — install span on the attempt that hit the network timeout
AntigravityInstallation.install  Failure
AntigravityInstallationError: Could not install Antigravity. Check free disk space and directory access, then try again.
  [cause]: HttpClientError: Transport error (GET https://dl.google.com/agy-extensions/releases/linux/agy-acp-server-1.4.5-linux-arm64.zip)
    [cause]: TypeError: fetch failed
      [cause]: ConnectTimeoutError: Connect Timeout Error (attempted address: dl.google.com:443, timeout: 10000ms)

Workaround

None on the same host. Run Antigravity on a different environment (x64 Linux, macOS, or a VM with a 4 KiB-page aarch64 kernel). The underlying fix needs a 16 KiB-compatible build from Google; the T3 side could fail fast with a clear message.