Bug: Windows: Antigravity install fails with "browser suppression could not be verified" — stale CHROME_CRASHPAD_PIPE_NAME makes the preflight helper print a Crashpad error to stderr #26368

Environment

• T3 Code (Beta) 0.1.3 (stable), Windows desktop app
• OS: Windows 11 Home (zh-CN), build 26300, x64
• Runtime files land fine; failure happens in the post-install validation step

What happens

1. Settings → Providers → Antigravity → Install Antigravity

2. The ~125 MB download and zip extraction complete successfully

3. AntigravityInstallation.validate → prepareAntigravityProfile fails within ~135 ms with:

   AcpTransportError: ACP transport operation failed: Antigravity browser suppression could not be verified.
       at authSupportError (.../binCli-tZsVKo_d.mjs:190383:9)
       at prepareAntigravityProfile (.../binCli-tZsVKo_d.mjs:192712:26)
       at AntigravityInstallation.validate (.../binCli-tZsVKo_d.mjs:192853:10)
       at AntigravityInstallation.install (.../binCli-tZsVKo_d.mjs:192890:16)
   

   wrapped as AntigravityInstallationError: The downloaded Antigravity runtime could not start in this environment.

4. The install rolls back, the UI returns to "Not found", and every retry repeats the full download + the same failure.

Evidence: the helper child actually starts fine and exits 0

Captured live with Procmon during a failing attempt — the server spawns the helper exactly as designed, and the child exits with status 0:

"16:11:47.0073080","T3 Code (Beta).exe","46380","Process Create","E:\Programs\T3Code\T3 Code (Beta).exe","SUCCESS",
  "PID: 72136, Command line: ""E:/Programs/T3Code/T3 Code (Beta).exe"" -e ""process.stderr.on(\""error\"",()=>process.exit(0)).write(\""__T3_ANTIGRAVITY_AUTH_URL__\""+JSON.stringify(process.argv[1])+\""\n\"",()=>process.exit(0))"" -- https://example.invalid/t3-antigravity-browser-preflight"
"16:11:47.0073778","T3 Code (Beta).exe","72136","Process Start","","SUCCESS", ...
"16:11:47.0921977","T3 Code (Beta).exe","72136","Process Exit","","SUCCESS","Exit Status: 0"

So exitCode === 0 is satisfied and the failure is purely the stderr-content equality check.

Root cause: a stale CHROME_CRASHPAD_PIPE_NAME pollutes the helper's stderr

Re-running the identical spawn (array argv, shell:false, extendEnv:false, same env object as antigravityEnvironment() produces, sourced from the live server process's PEB env block) reproduces the mismatch deterministically. The child prints one extra Crashpad line before the marker:

[1028/161424.288:ERROR:third_party\crashpad\crashpad\util\win\registration_protocol_win.cc:108] CreateFile: The system cannot find the file specified. (0x2)
__T3_ANTIGRAVITY_AUTH_URL__"https://example.invalid/t3-antigravity-browser-preflight"

(系统找不到指定的文件。 = "The system cannot find the file specified.")

Why: the running server's environment contained

CHROME_CRASHPAD_PIPE_NAME=\\.\pipe\crashpad_50144_ZUJNJELFHHXPBIRT

• PID 50144 no longer exists (dead process), and no pipe with that name is present in \\.\pipe\ (verified while the app was running).
• The helper child is the Electron exe running as Node (ELECTRON_RUN_AS_NODE=1), but because the env var is present, it still initializes the Crashpad client and attempts to connect to the pipe; the connection fails and the error goes to stderr.
• stderr.text !== "__T3_ANTIGRAVITY_AUTH_URL__\"<url>\"\n" → the exact-match check fails, and mapError maps the mismatch (and any other error in the block) to the generic "browser suppression could not be verified" message.

The stale value entered the process chain via the updater/installer launch path (the parent launcher chain carried it; a fully fresh relaunch of the app does not set this variable at all, verified by dumping the relaunched main/server env). Chromium/Electron trusts an existing pipe-name env var instead of creating its own, so the whole main→server→helper chain keeps pointing at a pipe that will never exist.

Fix that unblocked this machine

Fully exit T3 (kill every T3 Code (Beta).exe), then relaunch from a process chain that doesn't carry the variable (normal Start Menu launch). The helper's stderr is then clean, the preflight matches, and the install succeeds (validate 11 s ACP handshake → Success).

Suggested fix

In antigravityEnvironment, add CHROME_CRASHPAD_PIPE_NAME to removedEnvironmentKeys — the list already exists to strip/re-add keys like GEMINI_HOME and ELECTRON_RUN_AS_NODE. The preflight helper runs as plain Node and has no reason to connect to the app's Crashpad pipe, and this makes the preflight robust against stale/broken crash-reporter state inherited from launchers/updaters.

Optionally, also make the preflight tolerant of incidental stderr output (e.g. accept the marker line anywhere in stderr rather than requiring byte-exact equality) — same fragility class as the 5 s timeout variant (#20529) and the t3 -e variant (#11767).

Related

• [Bug]: Antigravity sessions fail to open when the browser-suppression preflight exceeds 5 seconds #20529 — same preflight, fails when it exceeds the 5 s timeout
• [Bug] Self-contained nightly service breaks Antigravity preflight by invoking t3 with -e #11767 / fix(server): Antigravity unusable on headless serve backends — browser-suppression preflight runs t3 -e, rejected by compiled binary #12245 / [Bug]: Stable v0.0.42 Antigravity install fails (t3 -e browser preflight) on Linux x64 #13215 — same preflight, fails when the helper is the compiled t3 binary (Linux serve)

Happy to provide the full server.trace.ndjson failure spans or additional dumps if useful.