Repository navigation
install.py: get_target_dir() and get_profile_dir() disagree on the ide flavor's directory #4
Description
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-operationsMCP 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.
Activity
dandye commentedon Jul 28, 2026
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 standardizingget_target_dir()on~/.gemini/antigravity/instead. That's wrong. I inspected a live machine running both apps and found:ps auxshows 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.jsonis a real, standalone file (not a symlink) — meanwhile~/.gemini/antigravity/mcp_config.jsonturned 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.--app_data_dirvalue is computed internally by Antigravity IDE's own shippedextension.js(getInstance().appDataDirectoryName) — it's not a user-configurable flag, so it isn't something a user's local experimentation could have produced.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()'sideflavor branch should returngemini_home / "antigravity-ide" / "skills", notgemini_home / "antigravity" / "skills".get_profile_dir()'s existing "preferantigravity-ideif 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.mdon the branch (see the "Confirmed Root Cause: Two Separate Applications" section), also cross-posted in #6.fix(install): unify ide/cli target and profile directory resolution (f…
dandye commentedon Jul 29, 2026
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.