[yaacovcorcos]

What Changed

• No console window on Windows for Antigravity. Agents that own their process tree (ownDetachedProcessGroup) were spawned detached on every platform. A detached Windows process has no console, so every console program it starts gets a new visible one. Antigravity's launcher starts its inner process that way, so each install check (and each Antigravity session) opened a Windows Terminal window titled with a path. In AcpSessionRuntime.ts (marked seam) the agent is now detached only off Windows. Windows already stops the tree with taskkill /T, so it shares Effect's hidden console and the inner process does too.
• A timed-out runtime check says so. When the post-download check of the Antigravity runtime outlived its 90-second limit, the error fell through to the install's catch-all "Check free disk space and directory access". It now reads: "Antigravity didn't finish starting within 5 minutes while Scient was checking it. Starting it can take a while on some computers. Try again." (marked seam in AntigravityInstallation.ts, one call site).
• 5 minutes for the agent to start. The install check, model refresh (AntigravityDriver.ts) and sign-out (AntigravityAuth.ts) allowed T3's 90 seconds; each now allows 5 minutes, in a marked line. Sign-in already allowed 5 minutes. The health check stays at 90 seconds, because it never starts the agent.

Why

Seen in the dev app on Windows: a Terminal window opened during Antigravity's install check, and the install then failed with the disk-space message on a machine with 265 GB free.

• Window: reproduced by starting the installed agy_acp_server.exe detached; Windows Terminal opened for its inner process at the same second. The detach came from Scient's ee950feee5; upstream T3 does not detach on Windows. Effect's Windows kill path uses taskkill /T whether or not the child is detached, and a non-detached child gets windowsHide.
• Message: the dev-app trace shows the check's agent initialized but never answered initialize before the 90-second timeout. The agent is a self-unpacking bundle: every start unpacks about 7,300 files (320 MiB) into a fresh folder, measured at about 35 s on this machine with no reuse between starts. So a slow check isn't only a loaded machine, and the message doesn't blame one. The owner also reports very slow installs on another Windows machine with free memory, so the steps that wait for a start now allow 5 minutes. The cost is that a start that truly hangs takes longer to report; the install check can still be cancelled.

The other two checks using the same timeout keep upstream's exact text: one falls back to downloading a replacement, and the other reports a publication failure; neither shows the timeout to the user.

Documentation Impact

Documentation impact: Updated — docs/user/providers-antigravity.md (Troubleshooting: 5 minutes, installation checks), UPSTREAM.md

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Tests: AntigravityInstallation.test.ts 51 pass / 1 skipped; AntigravityAuth.test.ts 29; AntigravityProvider.test.ts 23; AntigravityDriver.test.ts 2 pass / 24 skipped on Windows (CI runs them). New cases make the real check hang until its limit, and assert the message, taskkill /PID … /T /F, and that the process tree is stopped before the disposable profile is removed (Windows ARM fixture, three cleanup-error variants). They fail without the seam. The spawn assertion now expects detached only off Windows. Server and provider-acp typecheck clean.

Review: Codex, two rounds. Round 1 found no Windows teardown, console-signal or other-caller regression (Grok and Droid share the launcher) and asked for paired markers, a narrower seam and a teardown-proving test; round 2 approved with no findings. Round 3 (the 5-minute limits) approved with one nit, that the health check doesn't start the agent, which is applied.

Not verified: a live install through the packaged app on Windows with the fix (the window cause and the no-window behaviour of a non-detached spawn were each reproduced natively, but separately).

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.6 KiB	5.6 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	4.3 KiB	4.3 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.3 KiB	1.3 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	26.2 KiB	26.2 KiB	0 B (0.0%)	29.3 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.6 KiB	5.6 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	4.3 KiB	4.3 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.3 KiB	1.3 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	26.6 KiB	26.6 KiB	0 B (0.0%)	29.3 KiB	✅
Claude	Live turn messages	2	2	0 (0.0%)	8	✅

Baseline: 15893fa · PR result: 9bcf037 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Full compact HTTP snapshot with live cursor.

• Codex decoded thread snapshot: 133.1 KiB
• Claude decoded thread snapshot: 133.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.