[Bug bounty] unrelated "monk" text skips Antigravity MCP registration #19

Stage

Connect

Coding agent

Antigravity

Summary

The POSIX launcher silently skips Antigravity MCP registration whenever the exact JSON string "monk" appears anywhere in ~/.gemini/config/mcp_config.json, even when .mcpServers.monk is absent.

The guard is a whole-file text search:

grep -q '"monk"' "$mcp_cfg"

As a result, an unrelated preference, server description, or other JSON value containing the exact string prevents the launcher from adding the Monk server. Antigravity then has no Monk MCP connection even though monk-agent is healthy, and the launcher exits successfully without explaining why.

Reproduction

1. Create ~/.gemini/config/mcp_config.json with a healthy unrelated server and the exact string "monk" outside the Monk server key:

{
  "preferences": {
    "notes": "monk"
  },
  "mcpServers": {
    "existing": {
      "serverUrl": "http://127.0.0.1:9000/mcp"
    }
  }
}

2. Run scripts/start-monk-agent.sh while the companion health endpoint is available.
3. Inspect the config:

jq -e '.mcpServers.monk.serverUrl == "http://127.0.0.1:7419/mcp"' \
  ~/.gemini/config/mcp_config.json

The assertion exits 1. The file is unchanged and the launcher prints no registration warning.

I also reproduced this deterministically with an isolated HOME, a stubbed healthy companion response, and MONK_AGENT_PATH=/usr/bin/true; the launcher exits 0, but the assertion above exits 1.

Expected

The idempotence check should inspect the JSON path .mcpServers.monk, not search the whole file for the string "monk". If that key is missing, the launcher should add it while preserving unrelated configuration.

Actual

Any unrelated occurrence of the exact string "monk" causes an early return, so Antigravity remains disconnected from Monk.

Setup

• macOS 26.5.2, arm64
• Codex CLI 0.144.5
• Monk plugin 0.1.42
• jq 1.7.1
• The same guard is present in all three shipped POSIX launcher copies

Severity

Major: connect-stage blocker for affected Antigravity configurations. The companion is healthy and the launcher reports success, but the required MCP server is never registered.

Suggested fix

Use a structured check such as jq -e '.mcpServers.monk != null' (with the existing Python fallback where appropriate), then preserve the current idempotent return only when that specific key exists. Add a regression fixture where an unrelated JSON field equals "monk".