[Bug]: AntiGravity Provider Setup Fails After Upgrade

[pyromancerx]

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

Start with a 0.0.40 install with working managed AntiGravity and update to 0.0.42 through normal NPX upgrade process.

Expected behavior

AntiGravity should continue to work as a provider.

Actual behavior

AntiGravity stops working after update.
Reinstallation of managed antigravity fails with the error "The downloaded Antigravity runtime could not start in this environment."
The managed installation then rolls back and AntiGravity is not usable as a provider.

Impact

Blocks work completely

Version or commit

No response

Environment

Debian 13, 0.0.42

Logs or stack traces

Here is the exact root-cause analysis of why the managed Antigravity installation broke after upgrading T3 Code to version 0.0.42.
  ──────
  ### Root Cause Summary
  In T3 Code 0.0.42, the application was migrated to a standalone Node Single Executable Application (SEA) binary at t3.

  When T3 installs and validates the managed Antigravity ACP runtime, it tests a browser-suppression helper script to intercept OAuth sign-in URLs. The code assumes process.execPath is the
  Node.js executable and invokes itself with -e <script>. Because process.execPath is now the t3 executable itself, t3 rejects the -e flag, fails preflight validation, and automatically deletes
  the downloaded runtime.
  ──────
  ### Step-by-Step Breakdown of What Is Happening

  #### 1. Download & Extraction Succeeded

  When you click install, T3 successfully downloads and verifies the Antigravity ACP bundle from Google:

  • URL: https://dl.google.com/agy-extensions/releases/linux/agy-acp-server-agy_acp_server_1.1.1-linux-x86_64.zip
  • SHA-256: 38f62d01b32deb0907b3d39a71ec301fd36369f6ffd1cf262d4af385177f79df
  • Extracted files: agy_acp_server.par and localharness_external

  #### 2. The Validation Preflight Check Runs

  Before completing the installation, T3 runs AntigravityInstallation.validate which calls prepareAntigravityProfile.

  To suppress external browser windows when authenticating, T3 configures the BROWSER environment variable with an inline Node.js helper script (browserHelperSource):

    const runtimeExecutablePath = input.runtimeExecutablePath ?? (yield* HostProcessExecutablePath);
    const helperExecutable = platform === "win32" ? runtimeExecutablePath.replaceAll("\\", "/") : runtimeExecutablePath;
    const browserCommand = [
        helperExecutable,
        "-e",
        browserHelperSource,
        "--",
        "%s"
    ].map(quoteBrowserArgument).join(" ");

  Before launching Antigravity, T3 verifies that this browser suppression helper works by spawning a preflight test:

    const child = yield* spawner.spawn(make(helperExecutable, [
        "-e",
        browserHelperSource,
        "--",
        browserPreflightUrl
    ]));

  #### 3. Why It Fails in 0.0.42 (Regression from 0.0.40)

  • In version 0.0.40, T3 was executed with the system Node runtime (/usr/bin/node), so HostProcessExecutablePath (process.execPath) was node. Running node -e <script> succeeded.
  • In version 0.0.42, T3 is packaged as a standalone binary (/home/---/.t3/runtime/versions/0.0.42/t3). process.execPath is /home/---/.t3/runtime/versions/0.0.42/t3.
  • When T3 runs:
    /home/---/.t3/runtime/versions/0.0.42/t3 -e "<browserHelperSource>" -- "https://example.invalid/t3-antigravity-browser-preflight"
  The t3 CLI argument parser does not recognize -e:
    ERROR: Unrecognized flag: -e in command t3
  and immediately exits with code 1.

  #### 4. The Installer Rollback

  Because the preflight test exits with code 1:

  1. prepareAntigravityProfile fails with:
    AcpTransportError: ACP transport operation failed.
    (detail: "Antigravity browser suppression could not be verified.")

  2. AntigravityInstallation.validate fails with:
    AntigravityInstallationError: The downloaded Antigravity runtime could not start in this environment.
  (Recorded in server.trace.ndjson.7:20263-20265).
  3. T3's installer catches the validation error, aborts, and deletes the temporary installation directory, which is why the binary seems to disappear immediately after extraction.

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Triage

Confirmed, and this is a duplicate of #11767. The diagnosis in this report is correct for v0.0.42.

On that release, prepareAntigravityProfile still takes HostProcessExecutablePath (process.execPath) and preflights browser suppression with:

<execPath> -e '<browserHelperSource>' -- https://example.invalid/t3-antigravity-browser-preflight

A compiled t3 / SEA binary is not Node, so Effect CLI prints Unrecognized flag: -e in command t3 and exits 1. Managed install validation then surfaces The downloaded Antigravity runtime could not start in this environment and rolls back. The Antigravity ACP archive itself is fine.

This was already fixed on main by #12033 (bf55408a5, merged 2026-09-16): standalone hosts resolve a real node from PATH via resolveNodeExecutable and use that for the helper / BROWSER command.

v0.0.42 does not contain the fix (tagged 2026-09-15, before #12033). Nightlies from 2026-09-16 onward do (current: v0.0.43-nightly.20260922.2096). Same wash as #12245.

What to do

1. Upgrade off 0.0.42 to a 0.0.43 nightly (or the next stable that includes fix(server): resolve Node for standalone helper scripts #12033).
2. Ensure node is on the process PATH used by the upgraded install (systemd/npx service PATH, not only an interactive shell). If Node is only in nvm, expect: Antigravity sign-in requires Node.js. Install Node.js and make sure node is on PATH, then retry.

Closing as a duplicate of #11767.

[juliusmarminge]

Duplicate of #11767 (fixed on main by #12033; not in v0.0.42).