install.py: get_target_dir() and get_profile_dir() disagree on the ide flavor's directory

[dandye]

Summary

scripts/install.py resolves two different directories for the ide flavor depending on which function you look at, so a skills install and its MCP server config can end up split across two different Antigravity profile directories.

Root cause

get_target_dir() (used to decide where skills get installed) hardcodes the ide flavor to ~/.gemini/antigravity/skills:

elif flavor == "ide":
    return gemini_home / "antigravity" / "skills"

But get_profile_dir() (used to decide where the MCP config gets merged) prefers ~/.gemini/antigravity-ide/ when that directory already exists on disk:

if flavor == "ide":
    if (gemini_home / "antigravity-ide").exists():
        return gemini_home / "antigravity-ide"
    return gemini_home / "antigravity"

Both are meant to describe the same "ide" runtime profile, but they disagree whenever ~/.gemini/antigravity-ide/ exists.

Impact

Running python3 scripts/install.py --flavor=ide --mode=global on a machine where ~/.gemini/antigravity-ide/ exists:

• installs the SecOps skills into ~/.gemini/antigravity/skills/
• but merges the google-security-operations MCP server config into ~/.gemini/antigravity-ide/mcp_config.json

The skills load in one profile with no MCP server configured in that profile, and the MCP server is configured in a profile that never loaded the skills. There's no error at install time or at skill-invocation time — the SecOps tools simply aren't reachable.

Suggested fix

Have get_target_dir() and get_profile_dir() share one source of truth for the ide flavor's directory (e.g. have get_target_dir() call get_profile_dir() internally, or extract a single resolve_ide_home() helper both use), so skills and MCP config always land in the same profile.

---

Found while critically reviewing PR #2 / branch agy_plugin_v0001.

[dandye]

Correction (2026-07-29) — the original recommendation here was backwards

I filed this issue based on the assumption that ~/.gemini/antigravity-ide/ was an unconfirmed/legacy directory and recommended standardizing get_target_dir() on ~/.gemini/antigravity/ instead. That's wrong. I inspected a live machine running both apps and found:

• ps aux shows two separate, concurrently-running applications, not one legacy variant of the other:
  • /Applications/Antigravity.app (Desktop, v2.4.3) launches its language server with --app_data_dir antigravity --subclient_type hub
  • /Applications/Antigravity IDE.app (v2.1.1) launches its language server with --app_data_dir antigravity-ide --subclient_type ide
• ~/.gemini/antigravity-ide/mcp_config.json is a real, standalone file (not a symlink) — meanwhile ~/.gemini/antigravity/mcp_config.json turned out to be a symlink into ~/.gemini/config/mcp_config.json, i.e. it belongs to the Desktop app's own config chain, not a generic "IDE" path.
• The --app_data_dir value is computed internally by Antigravity IDE's own shipped extension.js (getInstance().appDataDirectoryName) — it's not a user-configurable flag, so it isn't something a user's local experimentation could have produced.
• The two apps carry fully independent version numbers (2.4.3 vs 2.1.1) and independent update cadences (Desktop self-updated same-day; IDE last updated ~6 weeks prior), which argues these are two currently-maintained sibling products, not one being a legacy remnant of the other pre-dating some "2.0" rebrand.

Corrected conclusion: ~/.gemini/antigravity-ide/ is the real, live, currently-in-use directory for the Antigravity IDE application specifically. ~/.gemini/antigravity/ belongs to the separate Antigravity (Desktop) application. So the actual fix is the opposite of what I originally suggested:

• get_target_dir()'s ide flavor branch should return gemini_home / "antigravity-ide" / "skills", not gemini_home / "antigravity" / "skills".
• get_profile_dir()'s existing "prefer antigravity-ide if it exists" check was actually onto something real — it just needs to be applied consistently to both the skills path and the MCP-config path, rather than only the latter.

Full writeup with the underlying evidence is in docs/antigravity_runtimes_config.md on the branch (see the "Confirmed Root Cause: Two Separate Applications" section), also cross-posted in #6.

[dandye]

Resolved in commit on agy_plugin_v0001 branch: get_target_dir() now uses get_profile_dir() so skills and MCP configs land in the same profile directory.