Antigravity 1.23.2 · macOS 26.5 · Apple M5 Max (Mac16,6)
google.antigravity extension v0.2.0
When a workspace window is closed, the corresponding Antigravity Helper (Plugin) extension-host process and its child language_server_macos_arm both fail to
terminate.
The pair stays alive indefinitely, with the exthost pinned at ~99% of one CPU core, ESTABLISHED TCP between them, and the --parent_pipe_path watchdog unix-domain socket still held open in the exthost.
In a single 41-hour session on my machine I currently have two independent orphan pairs running while only one workspace window is open.
This is not a one-off - it happens frequently.
Both ignore SIGTERM and require SIGKILL to clean up.
| process | PID | role | etime | %CPU | Mem |
|---|---|---|---|---|---|
Antigravity Helper (Plugin) |
28032 | exthost (orphan #1) | 04:40 | 99.1 | 34 MB |
language_server_macos_arm |
29529 | child of 28032 | 04:40 | 0.1 | 38 MB |
Antigravity Helper (Plugin) |
55751 | exthost (orphan #2) | 41 h | 99.3 | 20 MB |
language_server_macos_arm |
55875 | child of 55751 | 41 h | 0.3 | 32 MB |
Antigravity Helper (Plugin) |
56491 | active exthost (workspace ) | 41 h | 14.5 | 720 MB |
language_server_macos_arm |
56806 | child of 56491 | 41 h | 0.2 | 157 MB |
Root cause hypothesis
The exthost ↔ language_server lifecycle uses a watchdog socket passed via --parent_pipe_path:
- Both halves of the watchdog pair are still open in the orphan exthost.
- The TCP server on the exthost’s
--extension_server_portis stillLISTEN,with the language_server’s connections stillESTABLISHED. - The host’s log relay through to the editor’s output channel does break at the close instant, but the exthost process itself never reaches the step that closes the watchdog pipe. With those handles still open, libuv never drains.
This looks like a partial dispose: references that hold renderer-side payload are dropped (Mem goes from 4.1 GB → 20 MB after orphaning), but the codepath that closes the watchdog
socket and the language-server TCP server never runs.
Related existing reports
This is the same architectural class as #129054 — MCP Servers Spawn Per-Workspace (children of the exthost not cleaned up on workspace close), but for language_server_macos_arm rather than MCP servers and on macOS rather than Windows. The fix likely lives in shared exthost teardown code.
Available debug data
Will happily share the bundle (process trees, lsof, samples of orphaned processes, logs and extension list).