feat(agents): add Antigravity CLI (agy) as built-in agent

[ASRagab]

Add Antigravity CLI (agy) support

Fixes #152

Google is migrating Gemini CLI to the new Antigravity CLI (agy). On June 18, 2026 Gemini CLI stops serving Google AI Pro/Ultra and free Code Assist users; it remains only on paid/enterprise API keys. This adds Antigravity as a first-class agent so users have a working migration path — without removing Gemini CLI, which paid/enterprise users still rely on. Fully additive, no breaking change.

What changed

• Agent registry — new antigravity entry in DEFAULT_AGENTS (electron/ipc/agents.ts): command: agy, resume -c, skip-permissions --dangerously-skip-permissions, prompt_ready_delay_ms: 1000. Launched interactively like every other agent (prompt typed into the TUI, not passed as -p).
• Docker (forward-compatible scaffolding only) — ~/.gemini/antigravity-cli added to the shared-auth mount map (AGENT_CONFIG_DIRS) for settings/plugins; agy installed in the bundled image via the official installer (Go binary, not npm). See the auth note below — Antigravity is native-only.
• MCP guard — agy excluded from both --mcp-config emission paths (legacyMcpConfigArgs in src/lib/agent-args.ts and buildMcpLaunchArgs in electron/mcp/agent-args.ts), the same way Codex is excluded. agy has no --mcp-config flag; passing it would break launch. Scope consequence (intentional): because buildMcpLaunchArgs returns nothing for agy, Antigravity tasks get no parallel-code MCP coordinator wiring — i.e. no spawning of parallel-code subagents from inside an agy session. Safe default for this change; wiring agy into the coordinator (it configures MCP via plugins/config, not a CLI flag) is a follow-up if wanted.
• Gemini CLI untouched.

⚠️ Antigravity is native-only (no Docker isolation)

• Native (non-Docker) tasks work fully via the normal interactive sign-in — credentials cached in the host OS keyring (Keychain/libsecret).
• Docker-isolated Antigravity cannot authenticate. Login is keyring-only OAuth; a barebones agent container has no secret-service daemon to reach the keyring, and agy has no API-key environment fallback (an earlier ANTIGRAVITY_API_KEY assumption was unverified and is false — agy still enters OAuth with it set). Run Antigravity as a native task.
• The Docker bits are kept as additive scaffolding: the bundled image ships the agy binary and ~/.gemini/antigravity-cli (settings/plugins) is mounted when "Share agent auth" is enabled, so a future file-based / API-key auth path drops in cleanly.

Corrections from Codex review

• Mount path fixed: agy writes app data to ~/.gemini/antigravity-cli, not ~/.config/antigravity (verified against the installed binary).
• Removed the unsupported ANTIGRAVITY_API_KEY Docker auth claim (binary does not consume it).
• data/ runtime state (memory/sidecar state_store.db / stream_store) gitignored — it is generated local state, not source.

Verification

• tsc --noEmit clean; full test suite green (111 tests across persistence, agents, both agent-args, pty). pty.test.ts config-dir-mount table extended with the corrected agy path.
• New unit tests assert no --mcp-config is emitted for agy on both arg paths.
• Manual native smoke test (selector availability, prompt delivery, -c resume, skip-permissions) and a full docker build are pending hardware/Docker.

🤖 Generated with Claude Code

[johannesjo]

Thank you ver ymuch for this @ASRagab <3!

Multi-agent review

Reviewed by parallel Claude reviewers across correctness, security, architecture, alternatives, performance, and simplicity. The headline finding below was traced end to end through the PR-head code (including the backend StartMCPServer handler). Net: a clean, well-scoped, well-documented additive change with one issue worth addressing or consciously accepting before merge.

Verdict: NEEDS CHANGES (minor). Strong PR overall: faithful data-driven pattern, honest spec/docs (pending manual smoke tests correctly left unchecked), good coverage on both MCP-arg paths, accurate agy ground-truthing.

Address or accept: agy coordinator/coordinated tasks flip to a false "MCP error" on restart

src/store/tasks.ts (taskRequiresMcpLaunchArgs / applyTaskMcpLaunchResult), reached from App.tsx rehydration and the retry button in TerminalView.tsx.

agy is the only agent for which buildMcpLaunchArgs returns [] while a configPath is still written. In electron/ipc/register.ts the coordinator configPath is written for any non-Docker coordinator regardless of agent, then buildMcpLaunchArgs('agy', ...) returns [] (Codex returns a non-empty ['--config', ...]; all other agents return ['--mcp-config', ...]).

Consequence:

• On initial create, a coordinator task is set mcpStartupStatus: 'ready' unconditionally, so an agy coordinator looks fine.
• On app restart (and on manual retry), applyTaskMcpLaunchResult receives mcpLaunchArgs: []. Because Boolean(task.mcpConfigPath) is true (persisted from create), taskRequiresMcpLaunchArgs returns true and the task is marked markTaskMcpError('MCP startup returned no launch args').

So the same task reads ready on creation and error after every restart. It does not crash or lose data, and it only bites if agy is used in coordinator/coordinated mode (documented as having no MCP wiring), but nothing in the UI prevents selecting agy as a coordinator, so the path is reachable.

Note this is also a third copy of command detection: src/store/tasks.ts has its own isCodexCommand that was never updated for agy, which is why the site was missed.

Clean fix (small, in spirit): make taskRequiresMcpLaunchArgs treat agy as not requiring launch args, e.g. isCodexCommand(cmd) || (Boolean(task.mcpConfigPath) && !isAntigravityCommand(cmd)). Alternatives: gate coordinator mode off for agy, or do not persist mcpConfigPath for it. This lives in coordinator infrastructure this PR did not author, so scoping it as a follow-up is reasonable, but the ready-then-error inconsistency is real today.

Other warnings

• Dockerfile curl | bash installer is unpinned (docker/Dockerfile). curl -fsSL https://antigravity.google/cli/install.sh | bash -s -- --dir /usr/local/bin && agy --version pipes a remote, unversioned script into root at build time with no checksum or signature; && agy --version proves a binary installed, not which one. The npm install -g line above is also unpinned, but the repo's other network fetches (NodeSource, GitHub CLI) use GPG-verified apt keyrings, so this breaks that pattern. Blast radius is bounded (Docker only, and agy is documented native-only so the bundled binary is currently unused). Suggest pinning a versioned release plus a published SHA256 if upstream supports it, or at minimum documenting the supply-chain risk in design.md (it currently flags only reproducibility).
• openspec/changes/add-antigravity-agent/.openspec.yaml is inconsistent with the repo. None of the existing change folders carry a .openspec.yaml. Harmless (validation passes either way), but suggest dropping it unless adopting repo-wide.

Suggestions (optional)

• Consolidate the duplicated isCodexCommand / isAntigravityCommand detection (now in 3-4 places) and use the currently-dead AgentDef.mcp_config_flag field, or one shared module, as the source of truth. This is what would have caught the issue above. Pre-existing pattern and larger than this PR, so a reasonable follow-up.
• The agy coordinator preamble routes into the else (Claude) branch in coordinator.ts and writes to .claude/settings.local.json, which agy does not read (its config is ~/.gemini/antigravity-cli). Silent no-op in the unsupported coordinator path. Same root cause as above.
• Consider a one-line "why" comment on isAntigravityCommand's exact match (vs Codex's substring) and on the agy: ['.gemini/antigravity-cli'] nesting under gemini: ['.gemini'] in AGENT_CONFIG_DIRS, so neither gets "fixed" later.

Checked and cleared (not issues)

• No credential leak via the agy mount. The mount source is an isolated, fresh 0o700 per-agent dir (~/.parallel-code/agent-auth/agy/...), not the host's real ~/.gemini, and it is gated behind the share-auth opt-in. Verified against pty.test.ts.
• isAntigravityCommand exact match vs isCodexCommand substring is fine. Exact match is the safer choice for a short token like agy; not a defect.
• No meaningful performance impact. One extra TTL-cached which probe, one keyed selector row, no renderer-bundle delta, build-time-only Docker cost.
• AgentDef duplication (src/ipc/types.ts vs electron/ipc/agents.ts) is pre-existing and correctly left untouched (no new field added).

Note: a seventh reviewer (Codex CLI) could not run in this environment (read-only filesystem blocked its app-server init), so this summary reflects the six Claude reviewers plus manual verification.