feat(ai): add support for antigravity, opencode, and pi CLI integrations

[Paslestrange]

This PR adds auto-detection, configuration setup, and active diagnostic runner drivers for three additional AI agent CLI tools as requested in discussion #1252:

1. Antigravity (checks for the agy / antigravity binaries, configures ~/.gemini/antigravity-cli/config.json)
2. OpenCode (checks for the opencode binary, configures ~/.config/opencode/opencode.json)
3. Pi CLI (checks for the pi binary, configures ~/.pi/agent/mcp.json)

Key Changes

• Backend CLI Drivers (internal/ai/agent_antigravity.go, internal/ai/agent_opencode.go, internal/ai/agent_pi.go): Implemented the Agent interface drivers for these CLIs, mapping target prompt/remediation variables, session continuation flag mappings, model selectors, and standard output log stream parsing.
• Agent Resolution (internal/ai/agent.go, internal/ai/diagnoser.go): Added the new drivers to the resolveAgent switch-case and added them to agentCLICandidates to mark them as fully Supported by Radar's diagnosis executor.
• Auto-Detection (internal/ai/detect.go): Added the new agents to knownAgents and resolved binary names dynamically (such as mapping antigravity to agy dynamically via LookPath).
• Frontend Setup UI (web/src/components/home/MCPSetupDialog.tsx): Consolidated configuration generation helper methods and created accurate MCP configs matching each agent's native format and schema directory path structure.

Addresses discussion #1252.

---

Note

Medium Risk
New subprocess drivers and apply-mode flags (e.g. Antigravity --dangerously-skip-permissions) touch the diagnosis execution path; changes are additive with tests for command/config wiring, but mis-parsed streams or wrong MCP config could break investigations for users who select these agents.

Overview
Adds three new local AI agent backends so Radar can drive Antigravity (agy), OpenCode, and Pi for AI diagnosis—not just Claude, Codex, and Cursor.

Each backend implements the shared Agent interface: spawn CLI with Radar’s MCP URL, write per-tool config in the workdir, parse stdout into diagnoses and session IDs, and restrict execution to full-local only (no safeguarded profile).

Detection and routing extend knownAgents, agentCLICandidates, and resolveAgent (including agy / pi-coding-agent binary aliases). Provider env prefixes in scrubbedEnv widen slightly for non-Claude auth.

Web UI: diagnose settings use a dropdown when more than three agents are installed; model placeholders cover the new agents. MCP setup consolidates JSON helpers and documents Antigravity, OpenCode, and Pi paths and config shapes.

^{Reviewed by Cursor Bugbot for commit 54010f0. Bugbot is set up for automated code reviews on this repo. Configure here.}

[nadaverell]

Thanks again for pushing these integrations forward. We’ve now merged #1273, which adds the execution-profile and consent framework we wanted in place before adding more active diagnosis runners. Could you rebase this PR on main and adapt each new CLI to that framework?

For each agent, please declare only the execution profiles the CLI can honestly enforce. “Radar safeguards” requires verified isolation from the user’s other tools and MCP servers; otherwise expose only “Your setup,” validate that profile in the driver, and preserve the agent’s normal configuration/environment with the corresponding warning. In particular, Antigravity’s unconditional --dangerously-skip-permissions should not be presented as safeguarded unless the CLI also provides verified controls that disable its built-in and external tooling.

Please also address the current functional gaps before marking the agents supported: OpenCode should obtain its resumable sessionID from structured JSON output, and Pi’s Radar MCP access needs a verified/configured MCP extension rather than only writing a file Pi does not natively load.

Because these CLIs have independent config, tool-loading, streaming, and session semantics, please consider splitting them into one PR per agent if validating all three together becomes unwieldy. That isn’t required if you can verify each one thoroughly in this PR, but smaller PRs would let us review and land the proven integrations independently rather than blocking the whole contribution on the least-certain CLI.

The framework should keep each adaptation fairly contained: profile declaration, driver validation/behavior, and consent copy/tests for that agent. Happy to help clarify the intended contract.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b7a0a83. Configure here.}

[nadaverell]

thanks for rebasing and taking another pass at this. i took another look and i think there are still a few things to sort out before this is ready:

• the new consent surfaces aren’t in aiConsentVersions, so i think all 3 integrations currently fail at the consent step (and make test catches this)
• pi still seems to depend on the separate pi-mcp-extension, but we only write its config and don’t install/load/check for the extension
• i think the antigravity MCP paths/schema don’t match its current docs, and afaict the CLI still doesn’t expose a conversation id in print mode, so follow-up turns may not work
• the “full local” behavior is a bit inconsistent: we scrub most of the user’s env, while the UI says it uses their normal setup. opencode also uses --auto, while the UI suggests the CLI’s sandbox still applies
• this branch is behind main again, and the new agent catalog added on main probably needs updating too

maybe it makes sense to split these up? opencode looks closest to working end-to-end, while pi and antigravity seem to need a bit more integration work / upstream verification.

for each one, could you include a quick real smoke test covering MCP discovery, initial diagnosis, capturing the session id, a resumed follow-up, and an apply turn? then add tests around whatever args/config/output format that test confirms.

happy to help with the small radar-side cleanup once those behaviors are verified, but i’m a little wary of us filling in the missing pieces based only on the CLI docs.