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

[iiloni]

What happened

An existing Antigravity thread failed with ACP transport operation failed. Removing and reinstalling the Antigravity runtime then downloaded the runtime, but validation failed with The downloaded Antigravity runtime could not start in this environment.

T3 Code was running as a Linux background service installed through npx, with Android and remote desktop clients.

Diagnosis

This is a regression in the self-contained T3 executable, not an incompatible Antigravity binary or host environment.

prepareAntigravityProfile obtains HostProcessExecutablePath and invokes that executable with -e <browser-helper-source> to verify browser suppression. In the npm-based service used before the self-contained release changes, that executable is Node and accepts -e. In 0.0.41-nightly.20260914.1707, the service process executable is the self-contained t3 CLI. It parses -e as a T3 CLI flag, prints Unrecognized flag: -e in command t3, and exits 1.

The profile preflight converts the unexpected exit/output to a generic AcpTransportError. AntigravityInstallation.validate wraps that again as The downloaded Antigravity runtime could not start in this environment, hiding the real failure.

The same preflight runs before normal Antigravity session startup, explaining both symptoms. The direct reproduction below fails before agy_acp_server is launched. Current main at ec5ede5e6a1f2f9d564a5834462f47d1b7e5f0ec still has the same relevant implementation.

Steps to reproduce

1. On Linux x64, install t3@0.0.41-nightly.20260914.1707 as a background service using the npm launcher.
2. Configure the Antigravity provider and start or resume an Antigravity thread.
3. Observe ACP transport operation failed during prepareAntigravityProfile / session/start.
4. Remove and reinstall the managed Antigravity runtime.
5. The archive downloads, but validation fails with The downloaded Antigravity runtime could not start in this environment.
6. Deterministic minimal reproduction: invoke the installed self-contained t3 executable with the same -e browser-helper arguments used by prepareAntigravityProfile. It exits 1 because t3 does not recognize -e.

Version

0.0.41-nightly.20260914.1707 (9375c779707fb95c06670db6da87441720b2d2e2)

Environment

• Linux x64, kernel 6.19.8-3.surface.fc43.x86_64
• Node v26.8.2 in the triage shell
• T3 Code user-level systemd background service, installed through npx
• Android app and desktop app on another machine as clients
• Antigravity with personal Google OAuth

Evidence

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

Relevant trace sequence (UTC, paths redacted):

2026-09-14T16:55:10Z  prepareAntigravityProfile       5.40 ms  AcpTransportError: ACP transport operation failed.
2026-09-14T16:55:10Z  startSession                   55.48 ms  ProviderAdapterRequestError: ... session/start: ACP transport operation failed.
2026-09-14T17:11:59Z  prepareAntigravityProfile     728.57 ms  AcpTransportError: ACP transport operation failed.
2026-09-14T17:11:59Z  AntigravityInstallation.validate 730.21 ms  The downloaded Antigravity runtime could not start in this environment.

After rolling back, the same preflight through the Node executable succeeds deterministically:

__T3_ANTIGRAVITY_AUTH_URL__"https://example.invalid/t3-antigravity-browser-preflight"
exit=0

Related issues

• [Bug]: Antigravity turn ends on a dropped ACP stream: raw proxy error shown, no reconnect after a clean WebSocket close (1000) #11670 is in the same Antigravity/ACP area but is not a duplicate. It concerns an already-running model stream ending with EOF, followed by failed recovery after WebSocket close 1000. This report fails earlier during profile preparation, before the Antigravity ACP process is initialized.
• fix(server): preserve Antigravity startup diagnostics #9839 proposes preserving Antigravity startup diagnostics; it would improve the generic message but does not correct the self-executable -e invocation.
• The regression boundary appears related to build(server): make the CLI bundle loadable as a Node single-executable #11316 and feat(release): publish npx t3 as a launcher over per-platform executable packages #11607, which introduced the Node single-executable build and npm launcher over per-platform executables. The last known working nightly tested here predates those changes.

No exact duplicate was found by searching for the two user-facing errors and Unrecognized flag: -e.

Fix applied or workaround

Rolled the service back to 0.0.41-nightly.20260913.1675, which predates the self-contained executable transition:

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

The service is enabled and active after rollback, the browser-helper preflight exits 0 with the expected marker, and Antigravity has been reinstalled successfully with provider status ready.

The newer t3 update <old-version> --allow-downgrade path could not perform this rollback because the older nightly did not publish a self-contained release archive; invoking the older npm CLI's service update command worked.

Filed by

Codex (GPT-5.6-Sol High) via t3 triage.

[juliusmarminge]

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.