Summary
The Antigravity IDE spawns one persistent language_server.exe multicall schedule "<cron>" agentapi new-conversation … child process per configured Scheduled Task at startup, but never terminates these scheduler processes when the IDE exits. The orphans survive (parent PID dead), accumulate across IDE sessions over days, and — because they freeze the ANTIGRAVITY_LS_ADDRESS of the main language server that spawned them — become functionally dead weight after the next IDE start binds a new port (they can never fire their task again). They only consume RAM.
On a machine with ~75 Scheduled Tasks this escalated today to 504 orphaned language_server.exe processes holding 15.86 GB of RAM, effectively taking down the workstation until they were killed manually.
Environment
- Antigravity IDE 2.4.2 (main.log:
[AutoUpdater] Up to date (2.4.2)) - Windows 11 Pro (10.0.26200), x64
- ~75 Scheduled Tasks configured in the IDE
Steps to reproduce
- Configure several Scheduled Tasks in the Antigravity IDE (the more, the more visible).
- Start the IDE. Observe one
language_server.exe multicall schedule …child process per task (Task Manager /Get-CimInstance Win32_Process), all children of the main language server. - Quit the IDE. The log writes
Shutting down language server…— the main LS exits, but none of the scheduler children are reaped. Their parent PID is now dead; the processes remain. - Start and quit the IDE again on following days. A fresh generation of schedulers is spawned each time; the old orphans are never cleaned up or re-attached.
Observed evidence (2026-07-25)
- 504
language_server.exeprocesses, 15.86 GB working set in total, with creation-time clusters from 2026-07-22 08:25 / 09:24 / 09:27, 2026-07-24 19:05–19:23, and 2026-07-25 08:30 — i.e. one surviving generation per IDE session across four days. Parent PIDs of all orphaned clusters no longer existed. - After killing all of them and starting the IDE once more, it immediately spawned 66+ new schedulers at 09:10, which again survived the IDE shutdown at 09:20 (
main.log: AutoUpdater check 09:10:04,Shutting down language server…09:20:23). - Command line of the orphans (typical):
C:\Users\<user>\AppData\Local\Programs\Antigravity\resources\bin\language_server.exe multicall schedule "29 */4 * * *" agentapi new-conversation "…" - Related earlier diagnosis (June 2026, same installation): the schedulers freeze the env var
ANTIGRAVITY_LS_ADDRESSat spawn time; after the main LS restarts on a new port, every orphan logsfailed to fetch available models: dial tcp [::1]:<old-port> … actively refused iton each cron trigger. So the orphans are not only leaked — they are permanently broken.
Expected behavior
Scheduler child processes are part of the IDE session and should terminate with it (job object / process group on Windows, or explicit reaping on shutdown), or at minimum be detected and re-attached/reaped on the next IDE start instead of spawning a fresh generation on top of the old one.
Actual behavior
Orphaned scheduler processes accumulate unbounded across sessions (~28–83 MB each; with many tasks this reaches multi-GB scale within days) and are functionally dead due to the stale LS port.
Workaround used
Manually killing all language_server.exe processes; as a structural stop-gap, launching the IDE inside a Windows Job Object with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE so the OS reaps all children on exit.