[Bug] Self-contained nightly service breaks Antigravity preflight by invoking t3 with -e #11767

Activity

1. iiloni

   changed the title [-]Self-contained nightly service breaks Antigravity preflight by invoking t3 with -e[/-] [+][Bug] Self-contained nightly service breaks Antigravity preflight by invoking t3 with -e[/+] on Sep 14, 2026
2. juliusmarminge commented on Sep 14, 2026

   

   juliusmarminge

   on Sep 14, 2026

   Member

   More actions

   Triage

   Confirmed on current main (05e3bcbc). This is a T3 regression from the self-contained executable, not a bad Antigravity binary or host environment.

   prepareAntigravityProfile still assumes HostProcessExecutablePath (process.execPath) is Node and runs:

   <execPath> -e '<browserHelperSource>' -- <preflight-url>
   

   On the pre-SEA npm service that executable is Node, so -e works. After #11316 / #11607, a background service started through npx is the self-contained t3 CLI. Effect CLI then prints Unrecognized flag: -e in command t3 and exits 1.

   That preflight runs in two places:

   1. Antigravity session start (AntigravityDriver → prepareAntigravityProfile) → generic AcpTransportError / ACP transport operation failed
   2. Managed install validation (AntigravityInstallation.validate) → The downloaded Antigravity runtime could not start in this environment

   The same argv is also written into BROWSER, so the helper used for Google sign-in would fail the same way even if preflight were skipped. agy_acp_server is never launched.

   The SEA branch already exists (HostProcessIsExecutable / node:sea). Other helpers use hidden unlisted commands (__claude-history, __service-launcher, __service-preflight, __ssh-helper). Existing Antigravity tests pass because they run under Node.

   Not a duplicate of

   • [Bug]: Antigravity turn ends on a dropped ACP stream: raw proxy error shown, no reconnect after a clean WebSocket close (1000) #11670 — in-session ACP stream EOF / WS 1000 recovery
   • [Bug]: Antigravity installation fails with generic error on CPUs without AVX (crashes with SIGILL) #11414 — AVX / SIGILL crash of the native runtime
   • fix(server): preserve Antigravity startup diagnostics #9839 — would preserve startup stderr (so this would show Unrecognized flag: -e) but does not fix the invocation

   Suggested fix

   When HostProcessIsExecutable is true, invoke a hidden t3 subcommand that writes the existing __T3_ANTIGRAVITY_AUTH_URL__ marker to stderr. Keep node -e for the npm/Node host. Apply that to both the preflight spawn and the BROWSER command. Add a test that uses a non-Node HostProcessExecutablePath / HostProcessIsExecutable=true so this cannot regress silently.

   Workaround

   npx --yes t3@0.0.41-nightly.20260913.1675 service update --allow-downgrade

   Accepting as a high-severity provider bug. Any SEA-based service (not only Linux) should hit this; this report used Linux x64 + Android/desktop clients.
3. 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 14, 2026
4. MohtashamMurshid commented on Sep 15, 2026

   

   MohtashamMurshid

   on Sep 15, 2026

   Last edited by MohtashamMurshid

   Contributor

   More actions

   Confirmed on 0.0.41-nightly.20260915.1766 with a Linux x64 user-level systemd service.

   After repairing the service, both the launcher and server are on .1766, t3 service status reports healthy, and the HTTP endpoint returns 200. The failure still reproduces independently:

   <t3-runtime>/t3 -e '<browser helper>' -- https://example.invalid/t3-antigravity-browser-preflight
   ERROR
     Unrecognized flag: -e in command t3
   exit=1
   

   This also affects the gemini-api-key auth method. The instance had authMethod: gemini-api-key with a non-empty key, but provider startup still failed in prepareAntigravityProfile before the credential could be used. Earlier, with the same machine and managed ACP runtime, invoking agy_acp_server directly succeeded through initialize and session/new and returned the model catalog. That isolates the failure to T3's host-executable browser-helper preflight rather than OAuth, the API key, or the Antigravity runtime.

   No credentials or token values were included in this confirmation.

   There is also a separate reinstall symptom on this machine. After provider.install.remove succeeded at 2026-09-15T17:08:49Z, the subsequent reinstall attempt produced no provider.install.start RPC, download activity, staging directory, or active.json runtime record. The filesystem contained only the empty parent tools/antigravity-acp directory. The provider cache remained installed: false, canInstall: true, with Antigravity is not installed.

   So in this client session, reinstall was not reaching the known validation failure. It was not being initiated on the server at all. That may be a separate provider-setup UI/RPC issue from the self-contained -e regression.
5. juliusmarminge commented on Sep 16, 2026

   

   juliusmarminge

   on Sep 16, 2026

   Member

   More actions

   Fixed by #12033 — standalone builds now resolve Node from PATH for Antigravity's browser helper (and device helper scripts) instead of invoking process.execPath with -e.
6. juliusmarminge

   closed this as completedon Sep 16, 2026
7. Pipyakas commented on Sep 23, 2026

   

   Pipyakas

   on Sep 23, 2026

   More actions

   Independent confirmation on stable v0.0.42 / Linux x64 (CachyOS): same t3 -e preflight failure, install rolls back with The downloaded Antigravity runtime could not start in this environment. Full report: #13216. Local workaround: default the helper path to /usr/bin/node in prepareAntigravityProfile (same bytes as HostProcessExecutablePath expression) until a release ships #12033.
8. dineshkorukonda commented on Oct 1, 2026

   

   dineshkorukonda

   on Oct 1, 2026

   Last edited by dineshkorukonda

   More actions

   Hi, I'm running into what looks like a related Antigravity installation/runtime issue on @Pipyakas

   Environment

   • T3 Code: 0.0.44
   • OS: Ubuntu 24.04 LTS, x86_64
   • Node.js: v20.20.2
   • Antigravity CLI: 1.2.14
   • T3 is running as a user systemd service.

   What works

   The standalone Antigravity CLI works correctly:

   $ ~/.local/bin/agy --version
   1.2.14
   
   $ file ~/.local/bin/agy
   ELF 64-bit LSB pie executable, x86-64
   

   T3 itself is also running correctly:

   $ systemctl --user status t3code.service
   Active: active (running)
   
   $ systemctl --user show t3code.service -p ExecStart
   ExecStart=.../t3/runtime/versions/0.0.44/t3 __service-launcher
   

   The problem

   The issue is specifically the Antigravity provider. T3 shows:

   Antigravity is not installed.
   Install it in this environment or set a custom executable path.
   

   I also tried setting the custom binary path to /home/dinesh/.local/bin/agy, but T3 still does not recognize Antigravity as installed.

   The managed Antigravity runtime does not appear to be getting installed either:

   $ cat ~/.t3/caches/antigravity.json
   {
     "installed": false,
     "version": null,
     "status": "error",
     "message": "Antigravity is not installed. Install it in this environment or set a custom executable path."
   }
   

   $ find ~/.t3/tools -maxdepth 6 -type f 2>/dev/null | \
       grep -Ei 'antigravity|agy|localharness'
   

   This returns no results.

   Related issues

   I came across #11767 ("Self-contained nightly service breaks Antigravity preflight by invoking t3 with -e") and wanted to check whether the fix/workaround documented there is still relevant for 0.0.44.

   I also saw that the Node/helper-script issue was subsequently addressed by #12033, so I'm not sure whether this is still the same underlying problem or a different managed-runtime installation issue.

   Constraints

   I don't want to downgrade T3 or change the system Node.js version, since this server has other applications depending on Node 20.

   Question

   Is there a current workaround or configuration change for 0.0.44 on Ubuntu/Linux that would allow the managed Antigravity runtime to install/start correctly?

   Any pointers to the relevant fix/commit or recommended setup would be appreciated.