fix(antigravity): clean Windows runtime temp files

[ariszz]

What Changed

On Windows, run each Antigravity ACP process with an isolated runtime temp directory and remove that directory when the runtime shuts down.

Before allocating a new runtime directory, cleanup reclaims directories left by terminated T3 server processes after verifying an ownership marker that binds the directory name and owner PID. Cleanup retries transient filesystem failures, while unmarked directories, mismatched markers, and directories belonging to active T3 processes are preserved. The ownership marker is removed only after payload cleanup succeeds, preserving recovery after failed deletion.

Focused tests cover environment isolation, normal interruption cleanup, ownership-marker validation, pre-allocation orphan recovery, and protection of active runtime directories.

Why

The packaged Antigravity runtime uses PyInstaller, which extracts files into _MEI* directories. When these directories are created directly in the system temp folder and not removed, repeated launches can consume hundreds of gigabytes.

Giving each runtime an owned temp directory allows T3 to clean up its files without touching unrelated temporary data.

Testing

• vp test run src/provider/acp/AntigravityAcpSupport.test.ts — 33 tests passed
• vp run --filter t3 typecheck
• Targeted lint and formatting checks for all six changed files; rerun for the two updated files
• Earlier revision: manually launched and stopped the Windows desktop app twice; confirmed each launch's runtime temp directory was removed after shutdown
• New regression test verifies marker preservation after exhausted cleanup retries and recovery by a later sweep; failed before the fix and passes afterward
• Additional Windows test: all nine runtime folders from three refreshes were removed. Dev-runner shutdown left one marked folder; restart automatically reclaimed it.

Checklist

• This PR is small and focused
• I explained what changed and why
• No UI changes
• No animation or interaction changes

Originally implemented with GPT-5.6 Sol in Codex Desktop.
Reviewed and updated with GPT-6 Astra via Codex in T3 Code.

Fixes #9650

Note

Add scoped Windows runtime temp directory lifecycle to makeAntigravityAcpRuntime

• On Windows, each Antigravity ACP runtime now allocates a marked, process-specific temp directory and rewrites both TEMP and TMP in the spawn environment to point there; non-Windows launches are unchanged.
• Startup reclaims stale directories via reclaimOrphanedRuntimeTempDirectories, removing only marked dirs whose recorded owner PID is dead; invalid, mismatched, unowned, and live-owner dirs are left untouched.
• Scope cleanup via removeRuntimeTempDirectory retries six times with exponential backoff, preserves the ownership marker while contents are locked, and logs a warning on final failure instead of propagating it.
• The AntigravityAcpRuntimeInput interface now requires filesystem, path, and platform services; callers like makeAntigravityInstallation and AntigravityDriver.makeRuntime supply these instead of passing spawn/process fields.
• Behavioral Change: Windows ACP spawn inputs now ignore any caller-provided TEMP/TMP (all case variants) and use the runtime-owned directory; cleanup failures are suppressed after logging.

^{Macroscope summarized a2cab15.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — Every existing Windows Antigravity launch now uses a rewritten temp environment and a new owned-directory lifecycle, including cross-process orphan reclamation and retrying filesystem deletion. This is a substantial runtime behavior and cleanup-side-effect change rather than a small isolated fix, so the lifecycle and failure behavior merit human review.

^{You can add or adjust custom eligibility rules. Learn more.}

[andybergon]

We hit the matching Windows Temp accumulation on Nightly 0.0.40-nightly.20260907.1346 with managed Antigravity ACP 1.1.1: 204 _MEI* folders, approximately 202 GiB total in Temp, and zero free space on C:.

We preserved the folder metadata and sampled hashes before manual cleanup. The detailed report is in #9650 (comment).

Adding this as another affected installation and a data point from the September 7 Nightly. We haven't tested this PR's changes, so this is confirmation of the existing problem, not validation of the fix.

[dancingmadkefka]

encountered this also. Disabled antigravity

[Mchicao]

+1 — hit this in the wild, with numbers.

Windows 11, t3code with the Antigravity agent enabled. Found 145 orphaned _MEI* folders ≈ 108 GB in %TEMP%, each ~0.86 GB (payload: a 550 MB localharness binary + Google client libs + python310.dll). It had the system disk at 98%.

Data points that may help:

• Orphans only appear during working hours, several per hour — consistent with the health-check cadence rather than actual agent usage.
• Timeline correlates with an Antigravity update (language_server.exe updated Sep 2 ~21:00 local; the first orphans appear Sep 3).

Worth noting: on a second PC this was never a problem. That machine has Antigravity 2.12.2 installed too, but doesn't run t3code — after weeks of regular use it has zero _MEI* folders. So the harness cleans up after itself when it exits normally; the leak only shows up where the process gets force-terminated (i.e. where t3code's health checks run). That matches the theory behind this PR.

Temporary mitigation we're running locally: a small janitor that deletes %TEMP%\_MEI* older than 30 min every couple of minutes (in-use dirs survive via file locks). Happy to test the isolated, owner-marked temp-dir approach from this PR once it lands — thanks for working on it.

[rolandorojas]

Codex here, posting for this account’s owner. We also see this on nightly 0.0.41-nightly.20260909.1439: 237 Antigravity _MEI* folders totaling 261.90 GiB, with new folders about every five minutes. We have not tested this fix.

[JosephDemarest]

Another affected install, plus two mechanism data points that support this PR's approach over a "shut it down gracefully" alternative, and one question about the reclaim rule.

Environment: Windows 11 Pro 26200, T3 Code v0.0.40 (stable channel), managed runtime agy_acp_server_1.1.1. Runtime installed 14:43 local; first orphan appeared the same minute. By evening: 118 _MEI* directories, ~137 GB, C: down to 50 MB free. After cleanup, 11 new directories (~13 GB) in 8 minutes of ordinary use.

Why containing the extraction looks right, rather than trying to stop the process cleanly. I ran the bundled agy_acp_server.exe directly, outside T3:

• extraction is ~1.2 GB and lands in about 3 s;
• closing the child's stdin does not make it exit (still alive after 20 s), so there is no EOF-based graceful path;
• TerminateProcess (exit -1) leaves the entire extraction behind.

So every caller ends up force-killing it, and cleanup has to be owned by the caller, which is what this PR does. Redirecting TEMP/TMP per runtime also covers the probe path through makeAntigravityInstallation, the high-frequency trigger in #9650.

Question on reclaimOrphanedRuntimeTempDirectories. The sweep skips any directory whose encoded owner PID is still alive, and the owner is the long-lived T3 server process. If removeRuntimeTempDirectory exhausts its six attempts (~3.1 s total) the marker is deliberately preserved, but that residue can't then be reclaimed by the same server, because its own PID is alive. It waits for a T3 restart plus the next Antigravity launch. Would it be worth also sweeping own-PID directories that no live runtime scope currently holds, or sweeping once unconditionally at server startup? At the orphan rates reported here, a locked payload that survives until restart could still accumulate.

Haven't built this branch: this is confirmation plus a code read, not validation of the fix.

[MiloAgudelo]

Confirming this is needed, and the Windows leak is already huge in the wild.

On a 454 GB C: with the managed Antigravity provider enabled and the default 5-minute health interval, T3 left 148 _MEI* folders / ~167 GB in %LOCALAPPDATA%\Temp. That alone took the volume to 90% full. Creation times line up with checkAntigravityProvider (median 329.5 s between folders; latest _MEI at 19:58:31 vs cache checkedAt 19:59:03).

A scoped TEMP/TMP directory that T3 actually deletes after taskkill is the right fix. Until this lands, the default probe will keep dumping ~1.16 GB on every tick and eat the system drive.

Thanks for taking this — please merge it.

[juliusmarminge]

Superseded by #12008, which merged and closed #9650. Closing this PR as leftover hygiene.

[juliusmarminge]

Superseded by #12008, which shipped the per-process owned temp directory approach credited from this PR (without system-temp sweeps). Closing this as superseded.