Antigravity runtime temp-dir cleanup starves the server's file I/O for minutes, and successful title generations report a timeout and retry #23877

Activity

1. luquibu

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 22, 2026
2. Laguirre-Axoft commented on Oct 23, 2026

   

   Laguirre-Axoft

   on Oct 23, 2026

   More actions

   Same pool starvation, reached through a second path: the managed runtime install/update validation. On this machine it caused an 11-minute "reconnecting / did not answer" outage, and then the update was reported as failed even though validation succeeded.

   What happened

   In Settings → Providers → Antigravity, I started the update from the managed runtime 1.1.1 to 1.3.0. Within seconds, every thread and the Providers page showed "<host> is reconnecting" and "T3 Code on <host> did not answer". The backend kept listening on 127.0.0.1:3773 but GET /.well-known/t3/environment hung. Text generation on this machine is Claude, not Antigravity, so the title path described above was not involved.

   Diagnosis

   1. AntigravityInstallation.install downloads and extracts 1.3.0, then runs validate, which starts the new agy_acp_server.exe in %TEMP%\t3-antigravity-validate-*. PyInstaller unpacks its payload into _MEI* there: 3,426 files in 686 directories, 140 MB.
   2. Validation succeeded in 15.6 s. When its scope closed, the profile directory removal (AntigravityInstallation.ts:356-371) started the recursive delete. It ran at about 10 files/s, and every other async fs call waited behind it, including ServerSecretStore.get and the trace writer.
   3. The validation scope is closed inside the 90 s timeout: validate(...).pipe(Effect.scoped, Effect.timeout(VALIDATION_TIMEOUT)) at AntigravityInstallation.ts:657-666. The cleanup took about 11 minutes, so the install failed with TimeoutError once the delete finished. It never wrote .install-complete.json, the staging directory was removed, and active.json still points at 1.1.1.
   4. The user-facing message is the generic "Could not install Antigravity. Check free disk space and directory access, then try again." Retrying repeats the same outage and the same failure. This matches [Bug]: Windows Antigravity install/reinstall reports failure after successful validation because temp cleanup fails with EBUSY #18551's symptom (successful validation, failed install), with slow cleanup instead of EBUSY as the cause. The retry added by fix(server): Antigravity installs on Windows ARM #18472 does not help here.

   The directions above apply to this path too: run the validation profile cleanup outside the timed region, and keep the delete from occupying the shared pool.

   Steps to reproduce

   1. Windows 11, ESET Endpoint Security running, T3 Code desktop 0.1.2 with its local backend, managed Antigravity runtime 1.1.1 installed.
   2. Settings → Providers → Antigravity, start the update to 1.3.0.
   3. Watch %TEMP%\t3-antigravity-validate-*\_MEI* drain while polling GET http://127.0.0.1:3773/.well-known/t3/environment. It hangs until the directory is gone, and the app shows "reconnecting" the whole time.
   4. When the directory is gone, the endpoint answers again and the install reports the disk space / directory access error. The previous runtime stays active.

   Version

   0.1.2 (tag v0.1.2, commit 044f072), desktop app with its local backend. The t3 triage CLI was 0.1.2-nightly.20261022.3541. AntigravityInstallation.ts is unchanged on main through v0.1.3-nightly.20261023.3553.

   Environment

   Windows 11 Pro 10.0.26200 x64, 22 logical CPUs. ESET Endpoint Security running; Defender real-time protection off. Antigravity managed runtime 1.1.1 (sha 47cb50ee…) updating to 1.3.0.

   Evidence

   # server.trace.ndjson (UTC)
   03:01:23.940                  provider.install.start
   03:01:23.943                  GET https://dl.google.com/agy-extensions/releases/windows/agy-acp-server-1.3.0-windows-x86_64.zip
   03:01:29.978 -> 03:01:45.537  AntigravityInstallation.validate   15.6 s  Success
   03:01:23.940 -> 03:13:10.832  AntigravityInstallation.install   706.9 s  Failure
     AntigravityInstallationError: Could not install Antigravity. Check free disk space and directory access, then try again.
       [cause]: TimeoutError: Operation timed out after '1m 30s'
   
   # ServerSecretStore.get (plain readFile) during the cleanup
   03:01:49.628 -> 03:02:34.489   44.9 s
   03:02:53.1   -> 03:10:40.6    467.5 s  (8 concurrent calls, all the same)
   # environment.metadata.descriptor: 10 s Interrupted, repeatedly, from 03:02:19
   # First 200 again at 03:13:09, in 9 ms, right after the directory was gone.
   
   # Temp dir drain, local sampling
   %TEMP%\t3-antigravity-validate-FMgz2l\_MEI0000a7882: 3,426 files / 686 dirs / 140 MB at start
   3,292 -> 3,076 files in 21 s
   
   # Process sample during the outage
   backend: 16 ms CPU over 5 s; 465 "other" I/O ops per 10 s; 6 threads in Wait/Executive
   ekrn.exe (ESET): 1.42 M read ops, 7.7 s kernel + 2.6 s user CPU per 10 s

   Fix applied or workaround

   Nothing was changed on the machine. The backend recovered by itself when the delete finished. Workaround: do not retry the update from the UI on this machine until the cleanup moves out of the timed region; each attempt costs the same outage and fails the same way.

   Filed by

   Claude Code (claude-opus-5-5) via t3 triage
3. Laguirre-Axoft commented on Oct 23, 2026

   

   Laguirre-Axoft

   on Oct 23, 2026

   More actions

   Follow-up from the same machine: the slow delete is specific to the T3 Code executable, not to the files, Node, or Electron.

   Same script (fs.promises.rm(dir, { recursive: true, force: true })), same files copied from the live Antigravity _MEI tree, Electron binaries run with ELECTRON_RUN_AS_NODE=1:

   Executable	Fresh small files	Antigravity _MEI files
   node 22.23.3	665 to 2,614 files/s	10,775 to 11,658 files/s
   node 24.15.0	1,561 files/s	9,432 files/s
   VS Code Code.exe (Electron 43.7.7, Node 24.21.0)	3,170 files/s	10,632 files/s
   T3 Code (Beta).exe 0.1.2 (Electron 44.9.3, Node 24.22.0)	6 to 8 files/s	7 files/s

   The T3 Code rate matches the drain rate seen during the outages, so any recursive delete the backend does on this machine runs about 1,000x slower than the same delete from another process. ESET Endpoint Security 13.1 is the only real-time scanner here (Defender real-time protection off), centrally managed. During the outage ekrn.exe did about 1.4 M read ops per 10 s. Both binaries are validly signed. Not confirmed from ESET's own logs, so the exact module is unknown. Users on managed endpoints with similar policies will see the same cost, which makes doing the cleanup outside the shared pool and outside timed regions more important.

   Filed by Claude Code (claude-opus-5-5) via t3 triage