Claude Code × Antigravity + Codex + Copilot + Cursor + Grok + Kimi — MCP Bridge

Drive six external coding CLIs — Google's Antigravity (Gemini 3.8 Flash), OpenAI Codex, the GitHub Copilot CLI, Cursor, and the two experimental newcomers Grok Build and Kimi Code — as sub-agents inside Claude Code. Text answers, image generation, real repo work, and parallel swarms, on quota you already pay for.

One MCP server, six backends — four verified, two experimental. It exposes Google Antigravity, OpenAI Codex, the GitHub Copilot CLI, Cursor, and now xAI's Grok Build and Moonshot's Kimi Code to Claude Code as clean MCP tools so you can delegate work to a different model family mid-task — without leaving your terminal, and on the subscriptions you already have. Each backend is independent: install one, or all six.

• 🛰️ Antigravity (agy, Gemini 3.8 Flash High). Fast, cheap tool-calling — and the only backend with an image model. Its headless print mode (agy -p) historically had a stdout bug: it wrote the answer to the controlling terminal instead of its stdout, so anything capturing stdout got nothing (and, under a TUI, agy's text leaked into the host's prompt). agy 1.0.15 fixed this on Windows — -p now writes the clean answer to stdout — so the bridge prefers stdout and falls back to reading agy's own transcript files only when stdout is empty (older agy, non-Windows, or --sandbox runs). It still detaches agy from the terminal so older versions can't leak.

• 🤖 Codex (codex exec, OpenAI). A strong reasoner for real code/repo work. It writes its final message straight to a file the bridge asks for (no scraping), supports model selection, and has a real, enforced sandbox.

• 🐙 Copilot (copilot -p, GitHub). GitHub's agentic coder. Stdout-native like Codex (-s prints just the answer), with model selection (--model), a best-effort tool/path permission knob, and a deterministic resume mechanism (the bridge sets each session's UUID itself).

• ✳️ Cursor (cursor-agent -p, Cursor). Cursor's agentic coder, with the widest model menu — GPT, Claude, Grok, and Composer via --model (validated against cursor-agent models). Stdout-native like Codex/Copilot (--output-format text prints just the answer), an agent-enforced sandbox (read-only via --mode ask), and a deterministic resume mechanism (the bridge mints each chat's id itself via create-chat). No image model.

• 🧪 Grok Build (grok -p, xAI) — EXPERIMENTAL. xAI's terminal coding agent, and the only backend besides Codex with a real OS sandbox — though only on Linux/macOS. Stdout-native (--output-format json returns the answer and the session id), with -r resume, streaming-json for watch mode, and full swarm support. Never verified end-to-end — see below.

• 🌙 Kimi Code (kimi -p, Moonshot) — EXPERIMENTAL. Moonshot's terminal coding agent (Kimi K2 family). Stdout-native (--output-format text), resumes per working directory (-c). No sandbox — print mode auto-executes every tool, like Antigravity. Never verified end-to-end — see below.

They share the same niceties: a *_continue to resume a thread, a live "watch" window to see the agent work, a unified agent_swarm that runs many tasks in parallel across all backends at once, and *_status diagnostics that spend no quota. (Kimi is the one exception: no watch or swarm support yet — see Experimental backends.)

Why you'd want this

Related MCP server: mcp-cli-tools

The backends at a glance

The bridge normalizes every CLI into the same shape, but they differ where it matters. Pick per task. The four verified backends first; the two experimental ones follow.

🧪 The two experimental backends — and how you can help

Grok Build and Kimi Code are wired in exactly like the other four, with one honest difference: no authenticated round-trip has ever run against either. I don't have a SuperGrok / X Premium+ subscription or a Kimi plan, so I cannot prove they answer. They ship anyway because a bridge nobody can install is a bridge nobody can verify — and because the parts that usually rot are already pinned down.

What is verified live (each CLI installed, run, and observed — just never logged in):

What is NOT verified — everything behind the auth wall:

• the happy-path answer itself: Grok's json envelope (text / sessionId) and Kimi's stdout answer;

• that -r / -c really restore context;

• Grok's streaming-json event stream, which watch mode renders;

• whether Grok's sandbox profiles behave as documented (and note: auth is checked before --sandbox and -m are validated, so a bad value can't even be observed while logged out — which is why the bridge validates both client-side).

How to help

If you have either subscription, please open a verification issue. The template is a checklist — tick only what you actually saw. The first box ("a fresh ask returned a real answer") is worth more than all the others combined, and takes about a minute:

# 1. Does the setup look right? (spends no quota)
#    -> call grok_status / kimi_status from Claude Code
# 2. Does it answer?
#    -> call grok_ask("say hi") / kimi_ask("say hi")
# 3. If it fails, does the raw CLI fail the same way?
grok -p "say hi" --output-format json
kimi -p "say hi" --output-format text

That last command is the one I can't run from here, and it's what separates "the bridge is wrong" from "the CLI changed". Partial reports are welcome; so is a plain "it didn't work, here's the error".

How it works

All six backends run headless and one-shot per call; the bridge's job is to get a clean answer out of each and hand it to Claude Code as a plain string.

flowchart LR
    A([Claude Code]) -- "MCP tool call" --> B["bridge<br/>(server.py)"]
    B -- "antigravity_*" --> C[agy -p]
    B -- "codex_*" --> D[codex exec]
    B -- "copilot_*" --> E[copilot -p]
    B -- "cursor_*" --> F[cursor-agent -p]
    C -- "json / stream-json (1.1.8+)<br/>else stdout or transcript.jsonl / .db" --> B
    D -- "output-last-message file" --> B
    E -- "stdout (-s silent)" --> B
    F -- "stdout (--output-format text)" --> B
    B -- "plain text" --> A

Antigravity. On agy 1.1.8+ the bridge asks for structured output and reads a contractual field instead of guessing: plain calls use --output-format json and return its response, while watch mode uses --output-format stream-json and rebuilds the answer from the stream's terminal result event (the same shape the Cursor bridge already used). Both also carry a conversation_id, which the bridge records so antigravity_continue pins exactly the thread it last ran in that workspace.

Older agy has no such flag, so the original path stays: on 1.0.15+ (Windows) agy -p writes its clean answer to stdout and the bridge returns that; on older agy — or non-Windows, or a --sandbox run — stdout is empty and the bridge falls back to agy's own transcript at:

~/.gemini/antigravity-cli/brain/<conv-id>/.system_generated/logs/transcript.jsonl

For that fallback it locates the conversation via cache/last_conversations.json (falling back to the newest brain/ directory touched since launch), streams the transcript, and returns the final source=MODEL, status=DONE, type=PLANNER_RESPONSE entry — the answer, minus the intermediate tool-calling steps (or the SQLite .db agy dual-writes, when no JSONL exists). This fallback still runs on 1.1.8+ whenever a run yields no result, so nothing depends on the structured path alone.

Codex. codex exec is well-behaved: the bridge passes -o/--output-last-message <file> and codex writes its final message straight there — no scraping. Continue works by capturing the session id from codex's own rollout files (~/.codex/sessions/.../rollout-*.jsonl) and resuming with codex exec resume <id>, falling back to the newest on-disk session for that cwd after a server restart.

Copilot. copilot -p "<prompt>" -s runs a prompt non-interactively and prints the clean final answer to stdout — the bridge reads it there, no scraping. It runs headless with --allow-all-tools --no-ask-user --no-auto-update (so it never blocks on a prompt), and disables copilot's flaky builtin GitHub-API MCP by default for predictable latency (COPILOT_GITHUB_MCP=1 re-enables it). Continue is deterministic: copilot's --session-id <uuid> both sets a new session's id and resumes an existing one, so the bridge generates the UUID itself, pins it to the workspace, and resumes that exact session — falling back after a restart to the newest on-disk session (~/.copilot/session-state/<id>/workspace.yaml) whose recorded cwd matches.

Cursor. cursor-agent -p --output-format text --trust "<prompt>" runs a prompt non-interactively and writes the clean final answer straight to stdout — the bridge reads it there, no scraping (--trust trusts the workspace so it never blocks on a prompt). Continue is deterministic and race-free: cursor-agent create-chat mints a fresh chat and prints its id, so the bridge mints the id itself, pins it to the workspace, and resumes that exact chat with -p --resume <chatId> — no rollout-scraping. After a restart it falls back to the newest on-disk chat under ~/.cursor/chats/<md5(workspace)>/<chat-id>/ whose meta.json cwd matches (the chat-dir hash is itself md5 of the workspace path).

Set up in 60 seconds

Prerequisites — install whichever backend(s) you want, and sign in once each:

• Antigravity: install agy and sign in to Antigravity once (via the IDE or agy -i).

• Codex: install codex and run codex login once (ChatGPT account or API key).

• Copilot: install copilot (npm i -g @github/copilot, or winget install GitHub.Copilot) and run copilot then /login once (or set a COPILOT_GITHUB_TOKEN/GH_TOKEN env var).

• Cursor: install cursor-agent (curl https://cursor.com/install -fsSL | bash) and run cursor-agent login once (or set a CURSOR_API_KEY env var).

You don't need all six — the tools for a missing CLI simply report "not found" via their *_status tool.

Recommended — no clone, you control updates

With uv installed, register the bridge straight from PyPI under mcpServers in ~/.claude.json — no path to hardcode, no git pull to remember:

"agent-intern": {
  "command": "uvx",
  "args": ["agent-intern"]
}

uvx pins to the version it first caches and does not auto-upgrade, so you never run an update you didn't choose — important, since the bridge runs unsandboxed code: a surprise (or compromised) release can't execute until you opt in. You still get told when there's something to opt into: any *_status call reports whether a newer release is out, and Claude is instructed to pass that on when it sees it. (There's a startup check too, but it writes to stderr — that only reaches your MCP logs, not you.) Upgrade deliberately and restart Claude Code:

uvx agent-intern@latest      # fetch + run the newest release (refreshes uv's cache)

From source

Clone it instead if you want to hack on the bridge or pin a local copy:

git clone https://github.com/SinanTufekci/agent-intern.git
cd agent-intern
pip install fastmcp
python test_smoke.py        # 4 real round-trips (ask, continue, image, swarm) — prints four PASS lines

Then point Claude Code at the absolute path to server.py under mcpServers in ~/.claude.json:

"agent-intern": {
  "command": "python",
  "args": ["C:\\path\\to\\server.py"]
}

"agent-intern": {
  "command": "python3",
  "args": ["/path/to/server.py"]
}

Restart Claude Code. Twenty-one tools appear, each prefixed mcp__agent-intern__:

• Antigravity (5): antigravity_ask, antigravity_continue, antigravity_image, antigravity_image_swarm, antigravity_status

• Codex (3): codex_ask, codex_continue, codex_status

• Copilot (3): copilot_ask, copilot_continue, copilot_status

• Cursor (3): cursor_ask, cursor_continue, cursor_status

• Grok (3, experimental): grok_ask, grok_continue, grok_status

• Kimi (3, experimental): kimi_ask, kimi_continue, kimi_status

• Shared (1): agent_swarm — fans a list of tasks out across five backends in one run (everything but Kimi)

The single-prompt tools — Antigravity, Codex, Copilot, Cursor, and Grok — take a watch=true flag for the live browser view (Watch mode). Kimi has no watch mode yet.

"Use antigravity_ask to summarize the README of this repo in three bullets." → Claude routes the prompt through the bridge, agy reads the file under the workspace root, and the answer comes back as a plain string. Swap in codex_ask, copilot_ask, or cursor_ask to have GPT, Copilot, or Cursor do the same.

Tools

🛰️ Antigravity

🤖 Codex

🐙 Copilot

✳️ Cursor

🧪 Grok Build (experimental — unverified)

🌙 Kimi Code (experimental — unverified)

🐝 Shared

workspace defaults to the MCP server's current working directory. Point it at a real project dir for context-aware answers — every backend gives the model access to files under that root (Codex, Copilot, and Cursor honoring their sandbox).

sandbox now applies to Antigravity too. It used to be silently ignored there, so an agy task written as {"backend": "agy", "sandbox": "read-only"} ran completely unrestricted while reading as though it were fenced. "read-only" maps to agy's plan mode, "danger-full-access" says plainly that the worker is unrestricted, and "workspace-write" is refused — agy has no write scoping to offer, and accepting it would promise a fence that doesn't exist. Omitting sandbox leaves an Antigravity worker unrestricted, unlike every other backend, whose default is read-only: that long-standing default is left alone so existing file-writing swarms keep working, so fence agy explicitly when you want it fenced.

antigravity_image forces agy to save to an explicit absolute path — without one, agy falls back to its own scratch dir (~/.gemini/antigravity-cli/scratch/). It then corrects the file extension to match the real bytes: agy's image model picks the format itself (JPEG for photo-like images, PNG for flat graphics), so a requested out.png may come back as out.jpg. The returned path always reflects the true format.

🤖 Codex bridge — the well-behaved sibling

codex exec writes its final message to a file the bridge asks for via -o/--output-last-message, so the answer comes back without any scraping (where agy needed a transcript workaround before 1.0.15 fixed its stdout). Three things make Codex worth reaching for over Antigravity:

• Real sandbox. sandbox accepts read-only (default — reads and answers, writes nothing), workspace-write (may edit files under the workspace), or danger-full-access (no sandbox — avoid). Unlike agy's no-op --sandbox, codex's -s actually enforces this. codex exec has no interactive approval gate, so this flag is your safety boundary — opt into write access deliberately.

• Model selection works. model maps to codex's -m. (agy's --model works in print mode too as of 1.0.16; every backend now exposes the same model knob, except Kimi, which has no list to validate against.)

• Stronger reasoning. Codex is a coding agent, not an image model — there's no codex_image. Its strength is reasoning and real code/repo work; hand it the jobs that need a heavier model.

Auth. Uses your existing Codex login (ChatGPT account or API key). Run codex login once; check with codex_status. No new keys for the bridge to manage.

🐙 Copilot bridge — GitHub's agentic coder

The GitHub Copilot CLI (copilot, from @github/copilot) is stdout-native like Codex: copilot -p "<prompt>" -s runs a prompt non-interactively and prints just the final answer to stdout, so the bridge reads it there — no scraping. What makes it worth reaching for:

• Model selection. model maps to copilot's --model; auto lets Copilot pick. Unlike the agy and cursor tools, the bridge can't validate this — copilot exposes no non-interactive model list — and the working set is account-dependent: on a Copilot Pro account here, auto worked while gpt-5.3-codex, claude-sonnet-4.6, and even GitHub's own --help example gpt-5.4 were all rejected as "not available". So omit model (account default) or pass auto unless you know your plan's ids; an unavailable one errors immediately with copilot's message, costing a call.

• Deterministic, race-free continue. copilot's --session-id <uuid> both sets a new session's id and resumes an existing one, so the bridge generates the UUID itself and pins it to the workspace — no rollout-scraping. After a restart it falls back to the newest on-disk session (~/.copilot/session-state/<id>/workspace.yaml) whose recorded cwd matches.

• Fast by default. Runs with --allow-all-tools --no-ask-user --no-auto-update, and disables copilot's builtin GitHub-API MCP (--disable-builtin-mcps) because its flaky HTTP connect can stall a call up to ~60 s. Set COPILOT_GITHUB_MCP=1 to keep it (for Copilot's issue/PR/repo tools).

Sandbox is best-effort, not enforced. Unlike Codex's OS sandbox, copilot's boundary is tool/path permissions. The sandbox knob maps to copilot flags for a uniform cross-backend field:

• read-only (default) — auto-approves tools so it runs headless, then denies the local write and shell tools (--deny-tool). Best-effort: it is not an OS sandbox, and network/MCP tools can still act. For a hard read-only boundary, use codex_ask instead.

• workspace-write — writes allowed, but file access stays confined to the workspace (no --allow-all-paths).

• danger-full-access — --allow-all (tools + all paths + all URLs). Avoid.

Auth. Uses your existing Copilot login — run copilot then /login once (stored in the OS credential store), or set COPILOT_GITHUB_TOKEN/GH_TOKEN/GITHUB_TOKEN for headless use. Check with copilot_status. If copilot isn't on PATH (the winget install can land off a stale PATH), set COPILOT_BIN to its full path — e.g. %LOCALAPPDATA%\Microsoft\WinGet\Packages\GitHub.Copilot_*\copilot.exe.

✳️ Cursor bridge — the widest model menu

Cursor's agent CLI (cursor-agent, from cursor.com/cli) is stdout-native like Codex and Copilot: cursor-agent -p --output-format text --trust "<prompt>" runs a prompt non-interactively and writes just the final answer to stdout, so the bridge reads it there — no scraping (--trust trusts the workspace so it won't block on a prompt). What makes it worth reaching for:

• The widest model menu. model maps to cursor's --model (e.g. auto, gpt-5.2, claude-opus-4-8-high, composer-2.5, cursor-grok-4.5-high) — GPT, Claude, Grok, and Composer in one place, ~190 ids at the time of writing. cursor bakes the effort and speed axes into the id (…-low / -high / -xhigh / -max, each with a -fast twin), and also accepts a bracket form on the family base, e.g. claude-opus-4-8[context=1m,effort=high]. The bridge validates against cursor-agent models and rejects a typo up front (like agy), accepting either an exact id or a family base. Omit model to use your Cursor account default. cursor reshuffles this list often — run cursor-agent models (or cursor_status) rather than trusting an example here.

• Deterministic, race-free continue. cursor-agent create-chat mints a fresh chat and prints its id, and -p --resume <chatId> resumes that exact chat — so the bridge mints the id itself, pins it to the workspace, and resumes deterministically (no rollout-scraping, same idea as Copilot's self-set session id). After a restart it falls back to the newest on-disk chat under ~/.cursor/chats/<md5(workspace)>/<chat-id>/ whose meta.json cwd matches (the chat-dir hash is itself md5 of the workspace path).

Sandbox is agent-enforced, not an OS sandbox. Like Copilot, cursor's boundary is which tools the agent can reach, not an OS jail. The sandbox knob maps to cursor's mode/force flags for a uniform cross-backend field:

• read-only (default) — --mode ask: the write and shell tools are unavailable, so cursor analyzes and answers but makes no edits (verified: it refuses to write files). Agent-enforced and best-effort — it is not an OS sandbox. For a hard read-only boundary, use codex_ask instead.

• workspace-write — --force: edits and commands allowed, file access rooted at --workspace.

• danger-full-access — --force --sandbox disabled (OS sandbox off). Avoid.

(Cursor also exposes an OS-level --sandbox enabled/disabled; the bridge drives the uniform field via mode/force.)

Auth. Uses your existing Cursor login — run cursor-agent login once (OS credential store), or set CURSOR_API_KEY for headless use. Check with cursor_status. If cursor-agent isn't reliably on PATH (the installer drops a cursor-agent.CMD shim a bare name can't launch on Windows), set CURSOR_BIN to its full path — mirrors the AGY_BIN/CODEX_BIN/COPILOT_BIN overrides.

🧪 Grok Build bridge — a real sandbox, on two of three platforms

xAI's Grok Build (grok, installed with curl -fsSL https://x.ai/cli/install.sh | bash, or irm https://x.ai/cli/install.ps1 | iex on Windows) is stdout-native like Codex/Copilot/Cursor: grok -p "<prompt>" --output-format json runs a prompt non-interactively and writes a single JSON result object to stdout. What makes it interesting:

• It's open source. xai-org/grok-build publishes the actual CLI source, so this bridge's flag surface was read off the real clap definitions rather than inferred from docs — then confirmed against grok --help. That's a much stronger footing than a docs-derived bridge, and it caught a live discrepancy: xAI's own headless docs use -m grok-build in their examples, but the real default on 1.0.3 is grok-4.5.

• The answer carries its own session id. --output-format json returns {"text": …, "sessionId": …, "usage": …}, so the bridge pins that id and resumes the exact session with -r <id> — no id-minting dance like Cursor's, no rollout-scraping like Codex's. After a restart it falls back to -c, grok's own "most recent session for this cwd", so continue survives without ever reading grok's opaque SQLite session store.

• Free auth + model checks. grok models answers while logged out (exit 0, printing You are not authenticated. and the catalogue), so grok_status and model validation cost nothing and need no login.

Sandbox is real — on Linux and macOS. This is the only backend besides Codex with an OS-enforced boundary, but read the platform caveat:

• read-only (default) — --sandbox read-only plus a --tools allowlist (read_file,list_dir,grep,glob,web_search,web_fetch) plus --no-subagents.

• workspace-write — --sandbox workspace: writes land in the workspace, ~/.grok, and temp.

• danger-full-access — --sandbox off. Avoid.

Every mode also passes --always-approve: grok's headless mode does not auto-approve on its own (unlike agy and Kimi), and there's no human to answer a prompt. Containment comes from the profile and the allowlist, not from the approval gate.

Auth. grok login (browser OAuth), grok login --device-code (headless), or an XAI_API_KEY env var; credentials cache in ~/.grok/auth.json. Needs a SuperGrok or X Premium+ subscription. Check with grok_status. Set GROK_BIN to override the executable path — though the bridge already falls back to the installer's own ~/.grok/bin when grok isn't on PATH, which matters because the installer appends to the user PATH and that never reaches an already-running server process. GROK_HOME relocates the whole data dir. The bridge disables grok's background auto-updater per call via GROK_DISABLE_AUTOUPDATER=1 — a CLI that updates itself mid-session has broken this project before.

🌙 Kimi Code bridge — no sandbox, per-directory sessions

Moonshot's Kimi Code (kimi, npm @moonshot-ai/kimi-code) runs the Kimi K2 family. kimi -p "<prompt>" --output-format text writes the clean final answer to stdout.

• Continue is per-directory. Kimi scopes sessions to the working directory and exposes -c/--continue, so the bridge just re-runs with cwd=workspace and -c — no id to capture, and no restart problem. (-S/--session <id> exists but is deliberately unused: its on-disk format couldn't be verified.)

• No model validation. Kimi has no models command; aliases are user-defined in ~/.kimi-code/config.toml under [models."<alias>"]. model is a lenient pass-through, so a bad alias surfaces as Kimi's own run-time error.

• -p refuses --auto and --yolo (verified live on 0.29.1: "Cannot combine --prompt with …") because print mode is already self-approving — so the bridge passes neither.

Auth. kimi login (device-code OAuth) or an API key in ~/.kimi-code/config.toml (it does not read a bare env var). Check with kimi_status, which reads kimi provider list as the auth proxy. Set KIMI_BIN to override the executable path; KIMI_CODE_HOME relocates the data dir.

No swarm or watch support, deliberately — both would depend on Kimi's stream-json envelope, which no one has confirmed. They'll follow a successful verification report.

👁️ Watch mode — Agent Intern (experimental)

Pass watch=true to any single-prompt tool — antigravity_ask, antigravity_continue, antigravity_image, codex_ask, codex_continue, copilot_ask, copilot_continue, cursor_ask, cursor_continue, grok_ask, or grok_continue — to watch the agent work live in a little chat-style browser window called Agent Intern. The agent still runs headless; alongside it the bridge serves a tiny page on 127.0.0.1 and opens it in a small, chromeless app window that renders the exchange as a conversation: your prompt shows as a chat bubble, the agent's live steps stream in a collapsible "thinking" trace — its planner narration (▸), the real commands it runs ($), and completions (✓), read live (from agy's --output-format stream-json on 1.1.8+ — its transcript on older agy — or codex's / copilot's JSON event stream, or cursor's / grok's streaming-json) — and the final answer arrives as a Markdown card (and, for antigravity_image with watch=true, the generated image shown inline). A *_continue run opens with the prior turns of the conversation shown as history, so it reads as one ongoing thread rather than a blank new window. (A watched cursor_continue is the exception — Cursor stores its transcript in an opaque SQLite blob, so its window opens without visible prior-turn history.)

• Cross-platform & best-effort. Prefers a Chromium browser (--app mode) for the windowed look; falls back to a normal browser window. If nothing can open, the run still completes and returns normally.

• Window size. Set AGY_WATCH_WINDOW_SIZE (e.g. AGY_WATCH_WINDOW_SIZE=480,700) to resize the window; default is 560,760. Press Enter / Esc in the window to close it.

• One window, reused — but concurrent runs stay separate. Repeated sequential watch calls reuse the already-open window instead of stacking a new one (the open page resets itself for the new run; the swarm dashboard rebuilds for the new fan-out). A run that starts while another watched run is still working gets its own window instead — so two concurrent single-worker runs (e.g. a codex_ask and a copilot_ask at once) each stream into their own view and never clobber each other. If you closed the window, the next run opens a fresh one. Set AGY_WATCH_ALWAYS_NEW=1 to force a new window every time.

• Access control. The viewer is an HTTP server, and it serves your prompts, the answers, and the real commands the agents ran — so it binds 127.0.0.1 on an ephemeral port and requires two things on every request: a loopback Host header (which is what makes DNS rebinding fail — a rebound page arrives under the attacker's hostname) and a per-process token carried in the URL, which stops another local process or another user on a shared machine from simply connecting. The bridge puts the token in every URL it opens, so none of this is visible in normal use. Worth knowing because the server starts lazily but is never stopped: one watch=true run leaves the port listening for the life of the MCP server.

• Chat layout & history. Prompts render as chat bubbles (labelled CLAUDE, since the MCP client writes them) — long ones clamp to a few lines with a show more / show less toggle — and answers as Markdown cards tagged with the backend (AGY / CODEX / COPILOT / CURSOR). A *_continue run seeds the window with the conversation's prior turns, read from each backend's own session store (agy's transcript, codex's rollout, copilot's events.jsonl; Cursor's store is opaque, so a watched cursor_continue opens without visible history). The swarm's per-worker detail window uses the same chat design for its one task.

• Progress, keyboard & copy. Each panel shows a time progress bar (elapsed / timeout). The swarm dashboard adds an overall done/total bar and per-row time bars; use ↑/↓ to select a worker and ↵ to open its detail window. Answers render as Markdown with a copy button, and a "jump to latest" badge appears if you scroll up.

• Coarse, not token-level. The backends flush their step stream in chunks, so you get a handful of live steps, not character streaming. The returned value is identical to the non-watch call. Nothing is sent anywhere but your own machine.

🐝 Swarm — run agents in parallel

agent_swarm fans a list of tasks out to workers that run truly concurrently (capped at max_concurrency, default 4), then returns every worker's result in one block. Each task names its own backend, so a single swarm can mix Antigravity (Gemini), Codex, Copilot, and Cursor workers — hand the reasoning-heavy jobs to Codex, Copilot, or Cursor and the quick ones to Gemini, all at once. Good for independent sub-tasks: summarise N files, ask the same question about N repos, fix N bugs. (antigravity_image_swarm stays separate — it generates N images, and only agy has an image model.)

agent_swarm(tasks=[
  {"backend": "antigravity", "prompt": "Summarise src/auth.py in 2 bullets."},
  {"backend": "codex", "prompt": "Find and fix the failing test in tests/",
   "sandbox": "workspace-write", "workspace": "./repo"},
  {"backend": "copilot", "prompt": "Explain what src/api.py exposes.",
   "sandbox": "read-only", "workspace": "./repo"},
  {"backend": "cursor", "prompt": "Draft a docstring for src/utils.py.",
   "model": "auto", "workspace": "./repo"},
  {"backend": "grok", "prompt": "List the public exports of src/index.ts.",
   "sandbox": "read-only", "model": "grok-4.5", "workspace": "./repo"},
])

How it stays correct under concurrency. The single-agent agy tools serialize through a lock because agy rewrites last_conversations.json on every call, so concurrent runs sharing one state dir would race. The swarm sidesteps this: each agy worker runs with its own isolated HOME/USERPROFILE, so agy's brain/, cache/, and last_conversations.json never collide — no lock needed. Auth still works because agy reads it from the OS credential store, not from ~/.gemini (verified on agy 1.0.9). Codex, Copilot, and Cursor workers need no such isolation — each is a fresh one-shot (codex exec with its own -o file; copilot -p with its own self-set session id; cursor-agent -p with its own minted chat id). Each worker's cwd is its real workspace, so file access is unchanged. Measured ~2.8× speedup at 3 agy workers (the AI Pro backend does not serialize per-account); higher max_concurrency trades quota/rate-limit pressure for wall-clock.

• Per-task fields — backend (antigravity/codex/copilot/cursor/grok) and prompt are required; workspace defaults to the server cwd; sandbox and model apply to Codex, Copilot, and Cursor (ignored for Antigravity). Swarm workers are one-shot — there is no *_continue for a swarm worker's session.

• Error isolation — a worker that fails is reported in place; the others still return.

• watch=true — opens a thin live Agent Swarm dashboard (one row per worker, with a backend badge, repo, prompt, and latest step). Click a row to pop that agent into its own window streaming its full step log.

Model & auth

⚠️ Security

All six backends run the model as an autonomous agent. The difference is whether you get a real boundary: Codex enforces one everywhere and Grok on Linux/macOS only; Copilot and Cursor offer best-effort ones; Antigravity and Kimi offer none.

Antigravity — no usable boundary

agy -p executes its own tools — reading and writing files, running shell commands, reaching the network — with no approval gate. Through agy 1.1.2 that was simply how print mode worked, with no opt-out at all. As of 1.1.3 it is a choice the bridge makes: agy finally gates headless tool calls, and the bridge deliberately opts out with --dangerously-skip-permissions, because a gated -p can do no useful work (it soft-denies even a plain file read, and print mode has no way to prompt). The posture below is therefore unchanged — assume every call runs arbitrary code with your privileges. The one exception is the opt-in plan=True described in the last bullet; it is a real restriction, but an agent-enforced one, so it does not change the default posture. Re-verified empirically on agy 1.0.9 / Windows, with the 1.1.3 amendment noted:

• Print mode runs out-of-workspace file writes and live network fetches even without --dangerously-skip-permissions — that flag was a no-op for -p through 1.1.2. As of 1.1.3 it is load-bearing: without it every tool-using call is soft-denied, and the bridge now always passes it (it must precede -p, whose value is the prompt). There is still no agy flag that makes print mode both safe and useful.

• agy 1.0.5 integrated a permission system (its logs show toolPermission=request-review), but it still does not gate print-mode execution — a fresh -p run created a file outside the workspace with no prompt. agy 1.0.12 reshuffled how that permission config merges (per-project files under ~/.gemini/config/projects/ now take precedence over ~/.gemini/antigravity-cli/settings.json), and 1.0.13 made "Always Approve" rule matching strict (non-regex) by default with a regex: opt-in and relaxed its redirection checks — but those are config/interactive-approval changes, they add no print-mode approval gate, and the bridge reads none of it.

• --sandbox is not a usable boundary. agy 1.0.6 fixed its propagation into -p (the 1.0.6/1.0.7 changelog calls this "sandbox isolation correctly enforced") and it now does block terminal/ shell command execution — but re-verified on 1.0.9 that it leaves the write_to_file tool and network wide open: under --sandbox the model still wrote a file outside its workspace. agy 1.0.9 hardened the sandbox's command path (stricter exact-match command checks; .git added to its dangerous-paths list), but none of that closes the out-of-workspace write_to_file hole. On top of that, a --sandbox run whose blocked terminal command halts it writes no JSONL transcript (only the SQLite .db, re-confirmed on 1.0.9). The bridge can now read that .db, but still never passes --sandbox — it's no boundary, with file writes and network left open.

• ✅ plan=True is the first Antigravity restriction that actually holds — opt-in, per call, on antigravity_ask / antigravity_continue, and gated at agy 1.1.12 (older agy parses --mode and ignores it in print mode, so the bridge refuses rather than handing back an unrestricted run that reports success). It maps to agy's --mode plan: agy investigates and writes an implementation plan into its own directory instead of touching yours. Verified on 1.1.20 through the bridge's own code path, with a control: the identical prompt — cmd /c echo SHELLRAN > <absolute path> — executed and created the file on a normal call, and on plan=True created nothing at all, answering with a plan document. File reads still work, so it is genuinely useful rather than merely inert. Note what it is not: it constrains agy's agent loop, so it is agent-enforced like Copilot's and Cursor's modes, not an OS boundary — for that, use Codex (with the Windows caveat in Security firmly in mind). Two consequences worth knowing: it survives --dangerously-skip-permissions (which the bridge still passes, because dropping it would soft-deny the reads plan mode exists to allow), and it is mutually exclusive with the slash-command shield — agy silently disables plan mode when --disable-slash-commands is present, so the bridge drops that flag and rejects a prompt whose first token is a slash command instead.

Codex — a real sandbox you should use

codex exec also has no interactive approval gate, but its sandbox flag is a genuine boundary that codex enforces:

• read-only (default) — reads and answers; writes nothing. Safe for untrusted questions on trusted content.

• workspace-write — may edit files under the workspace. Opt in deliberately, per task.

• danger-full-access — no sandbox at all. Avoid.

Because there's no approval prompt, the flag you pass is the safety decision — choose it per call.

⚠️ On Windows, as of codex 0.149.1, that boundary is currently too tight to be useful — and it fails silently. Every command is refused under both read-only and workspace-write (down to pwd) with rejected: blocked by policy: codex's policy engine can't classify the pwsh -Command <...> wrapper codex itself builds. Shell commands are how codex reads files, so a sandboxed run sees nothing of your workspace — and says nothing about it. Asked for the version in a local pyproject.toml declaring 0.27.0, it web-searched and answered 1.2.0 from an unrelated GitHub repo; with the sandbox off, 0.27.0. Exit 0 both times. Known upstream (#40060, #38886). The bridge can't fix it, but it no longer launders it: any answer whose run had commands refused comes back with a visible [agent-intern] WARNING naming the count. Until it's fixed upstream, treat a sandboxed codex answer on Windows as unsourced unless that warning is absent.

Copilot — best-effort, not an OS sandbox

copilot -p runs headless with --allow-all-tools (required — otherwise it blocks on per-tool permission prompts). Its sandbox maps to copilot's tool/path permission flags, which are a real-ish but not enforced boundary:

• read-only (default) — auto-approves tools to run headless, then denies the local write and shell tools (--deny-tool). Blocks local file edits and command execution, but it is not an OS sandbox: other tools (including network/MCP) can still act. Weaker than Codex's read-only.

• workspace-write — writes allowed, but file access stays confined to the workspace (no --allow-all-paths).

• danger-full-access — --allow-all (tools + all paths + all URLs). Avoid.

For a hard read-only boundary, prefer codex_ask.

Cursor — best-effort, agent-enforced

cursor-agent -p runs headless with --trust (and --force when writes are allowed). Its sandbox maps to cursor's mode/force flags — an agent-enforced, not OS-level, boundary:

• read-only (default) — --mode ask: the local write and shell tools are unavailable, so cursor analyzes and answers but makes no edits (verified: it refuses to write files). Like Copilot, this is agent-enforced and not an OS sandbox. Weaker than Codex's read-only.

• workspace-write — --force: edits and commands allowed, file access rooted at --workspace.

• danger-full-access — --force --sandbox disabled (OS sandbox off). Avoid.

For a hard read-only boundary, prefer codex_ask.

Grok — real, but only on Linux and macOS

grok -p runs headless with --always-approve (its headless mode does not auto-approve on its own, and nothing is there to answer a prompt). Its sandbox maps to grok's OS profile plus a tool allowlist:

• read-only (default) — --sandbox read-only + --tools read_file,list_dir,grep,glob,web_search,web_fetch

  • --no-subagents.

• workspace-write — --sandbox workspace: writes confined to the workspace, ~/.grok, temp.

• danger-full-access — --sandbox off. Avoid.

The profile is enforced by Landlock (Linux ≥ 5.13) and Seatbelt (macOS). On Windows there is no mechanism, and per xAI's docs grok "logs a warning and continues without enforcement" — so on Windows the only thing standing between read-only and your disk is the agent-enforced tool allowlist. Treat Windows read-only as best-effort (Copilot/Cursor tier), not as a jail. The bridge uses an allowlist rather than a denylist so that a future grok with a new write tool fails safe; note that MCP meta-tools remain available under an allowlist regardless.

⚠️ This backend is unverified — including these sandbox claims, which could not be exercised, because grok checks auth before it validates --sandbox.

Kimi — no boundary at all

kimi -p has no sandbox and no sandbox argument. Print mode auto-executes every tool call with no approval gate — the same posture as Antigravity, and verified live on 0.29.1 in the sense that -p rejects --auto/--yolo precisely because it is already self-approving. No flag makes it safe. Assume every kimi_ask runs arbitrary code with your privileges.

What that means for you

• The workspace argument is only a starting context, not a security boundary — Antigravity and Kimi can and do act outside it; Codex is bounded by its enforced sandbox; Grok by its OS profile on Linux/macOS and by a tool allowlist elsewhere; Copilot by its best-effort tool/path permissions; Cursor by its agent-enforced mode/force.

• An Antigravity or Kimi call effectively runs arbitrary code with your user privileges. A Copilot or Cursor call does too outside its best-effort denials; a Grok call does on Windows outside its allowlist; a Codex call does unless you keep it at read-only.

• Only invoke these with trusted prompts on trusted content. Untrusted input here is the classic prompt-injection lethal trifecta: private-data access + code execution + network egress.

• For real isolation, run the whole bridge inside a container or VM.

The bridge itself does only cross-platform filesystem reads under ~/.gemini/antigravity-cli/, ~/.codex/, ~/.copilot/, and ~/.cursor/ — no private APIs, no token theft. The risk above is entirely in what the sub-agents are allowed to do.

FAQ

It runs the official agy, codex, copilot, and cursor-agent CLIs under your own logins — no private APIs, no token theft, no quota abuse. It just bridges what the CLIs already do. That said, your AI Pro / Antigravity, OpenAI / Codex, GitHub Copilot, and Cursor ToS apply, and you're responsible for staying within them.

No. Each backend is independent — install only the CLI(s) you want. The tools for a missing backend report "not found" via their *_status tool (antigravity_status / codex_status / copilot_status / cursor_status / grok_status / kimi_status) and never crash the server.

It does now, by default. The server ships an instructions block that Claude Code loads with the tool list, and as of 0.29.0 that block tells it to offer delegation in one line before starting a task that fits — bulk mechanical work, a job that splits into independent parallel subtasks, or a second opinion on a risky diff — and to ask rather than just spend your quota. It's also told to ask once per task, not once per turn, and to drop it if you decline, because a suggestion on every task is nagging rather than help.

MCP instructions are guidance, though, not a rule the harness enforces — so if you want it reliably proactive, put it where Claude Code treats it as an instruction. Add this to your project or global CLAUDE.md:

## Delegating to sub-agents

The `intern` MCP server bridges Antigravity/Gemini, Codex, Copilot and Cursor as sub-agents
running on my own subscriptions. Before starting bulk mechanical work (a rename across many
files, boilerplate, a first-pass port), or anything that splits into independent parallel
subtasks, propose delegating it in one line and wait for my answer — e.g. "this is 6
independent files, shall I farm it out to Gemini in parallel?". Pass `workspace` = the repo
root. Don't propose it for small tasks or work that needs our conversation's context.

Turn it the other way — "never delegate without me asking first" — and that works too: the same file, the opposite sentence.

Use Antigravity for fast, cheap tool-calling, quick answers, and image generation (it's the only backend with an image model) — and it now lets you pick the model too (agy's --model). Use Codex for heavier reasoning, real code/repo work, or when you want a real, enforced workspace-write sandbox. Use Copilot for agentic coding on your GitHub Copilot plan, or as a second coding opinion alongside Codex — noting its sandbox is best-effort, not enforced. Use Cursor for agentic coding on a Cursor plan, or when you want the widest model menu — GPT, Claude, Grok, and Composer, all via model — noting its sandbox is agent-enforced, like Copilot's.

Grok and Kimi are experimental and unverified — reach for them to help verify them, or if they're the subscription you actually have. Grok is the more capable of the two here: real OS sandbox (Linux/macOS), watch mode, and swarm support. Kimi has no sandbox and no swarm/watch yet.

All of them let you choose a model (except Kimi, which can't validate one); in a swarm you can mix five of the six. See The backends at a glance.

Less likely now. As of agy 1.0.15 the bridge prefers agy's stdout on the happy path (1.0.15 fixed the print-mode stdout bug on Windows — -p now writes the clean answer there), which removes its dependence on agy's undocumented transcript schema for normal runs. It still falls back to reading the JSONL transcript, or the SQLite .db agy dual-writes, when stdout is empty (older agy, non-Windows, or --sandbox runs) — so a schema change would only bite that fallback path. Re-verified working on 1.0.15 (stdout answer clean under tool use; transcript/.db fallback intact; live ask round-trip + antigravity_status diagnostics pass). Still, if you rely on the fallback, pin a known-good agy version.

Yes. Pass model to antigravity_ask/antigravity_continue (or per task in agent_swarm) — it maps to agy's --model, taking any slug from agy models (e.g. "gemini-3.1-pro-high", "claude-sonnet-4-6"). Omit it to use the "model" field in agy's settings.json, which defaults to gemini-3.8-flash-high — speed-optimized for cheap tool-calling.

agy 1.1.5 renamed every model, replacing the old human labels ("Gemini 3.1 Pro (High)") with stable slugs (gemini-3.1-pro-high) — the old form is no longer accepted, so pass slugs. The default has since moved three times: 1.1.6 added the gemini-3.6-flash family and took it, the gemini-3.7-flash family arrived by 1.1.16 and took it in turn, and 1.1.25 added gemini-3.8-flash and moved the default onto that (verified through the bridge: a call passing no model answers as Gemini 3.8 Flash). The same release also dropped the whole gemini-3.5-flash family, which no changelog entry mentions — a 3.5 slug from older docs is now rejected up front. The full list, re-checked live on 1.1.25: gemini-3.8-flash-low|medium|high, gemini-3.7-flash-low|medium|high, gemini-3.6-flash-low|medium|high, gemini-3.1-pro-low|high, claude-sonnet-4-6, claude-opus-4-6-thinking, gpt-oss-120b-medium. Note the slug bakes in the reasoning effort, which is why the flash and pro models appear once per level. agy self-updates in the background, so treat any list written down here — this one included — as a snapshot; agy models and antigravity_status are the live answer.

agy 1.0.5 added --model, but through ~1.0.14 switching to a different model in -p hung the call, so earlier bridge versions stayed single-model. Re-verified on agy 1.0.16 that the hang is fixed — a Claude model answers as Anthropic Claude, a Gemini model as Gemini, each in seconds. One caveat the bridge handles for you: agy silently ignores an unknown model (it falls back to the default with no error), so the bridge validates your slug against agy models and rejects a typo up front. (That validation is also what agy 1.1.11 broke, by making agy models print <slug>\t<human label> instead of a bare slug — see Status & caveats. Fixed as of bridge 0.24.0; on 0.23.x with agy 1.1.11+, pass no model at all.)

Yes — that's the antigravity_image tool, on the Antigravity backend. agy's print mode generates real images on your AI Pro quota; antigravity_image drives it, saves the file to a path you choose (or a timestamped default in your workspace), fixes the extension to match the real bytes (agy picks JPEG or PNG itself), and returns the path. Verified on agy 1.0.9 / Windows. Codex has no image model — it's a coding agent.

No. It uses the same quota you already pay for — AI Pro for Antigravity, your Codex plan for Codex, your GitHub Copilot plan for Copilot, your Cursor plan for Cursor. The smoke test spends a negligible amount.

The final answer is request/response — the CLIs return it all at once, so the tools return when the agent finishes (each call typically takes 10–30 s; Copilot's reasoning models can run longer). If you want to watch the agent work as it goes, pass watch=true to any single-prompt tool: it opens the Agent Intern browser window and live-streams the agent's steps — see Watch mode. It's coarse (a handful of steps, not token-by-token), and the returned value is identical to the non-watch call.

The single-agent tools are serialized inside the server: agy rewrites last_conversations.json on every call, so concurrent runs sharing one state dir would race and could return the wrong conversation. A threading.Lock makes extra requests queue rather than race. (On agy 1.1.8+ the bridge also records the conversation_id agy reports for each run and prefers it when pinning a continue, so that resolution no longer depends on the shared file — but the lock stays, since agy's state dir is still shared and a fresh server process starts with nothing recorded.)

For real parallelism use agent_swarm — each agy worker runs in its own isolated state dir (and Codex/Copilot/Cursor workers need none), so they don't race and the lock isn't needed (~2.8× at 3 workers). That's the supported way to run many calls at once, across any backend.

The isolated state dir is a redirected HOME, and on macOS that also hides agy's stored credentials (the login keychain is resolved through $HOME), so isolated workers there fall back to running serialized in your real HOME — correct, but without the speedup. Windows is unaffected (Credential Manager is HOME-independent). See the swarm auth note.

Status & caveats

• 🧪 Grok Build and Kimi Code ship UNVERIFIED — help wanted. Two new backends, neither ever exercised against an authenticated account, because I have neither subscription. This is a deliberate trade: shipping them unverified is the only way anyone can verify them, and the parts that historically rot — flag surfaces, model ids, error shapes — are pinned down live against grok 1.0.3 and kimi 0.29.1. Grok's are unusually solid, since its CLI is open source: every argv the bridge builds was read off the real clap definitions and confirmed to parse. What's unproven is everything behind each CLI's auth wall — the answer itself, resume, and Grok's streaming events. That verification gap already caught one live docs error (xAI documents grok-build as the model; the real default is grok-4.5), which is a fair warning about what else the docs may be wrong about. If you have either subscription, one issue from the verification template closes this gap. Full detail →

• 🐛 agent_swarm antigravity workers died with "authentication timed out" on macOS — fixed (#2). Each swarm worker gets an isolated HOME so agy's per-process state can't collide. The module shipped asserting that auth survives it because agy reads credentials from the OS credential store — true on Windows (Credential Manager is keyed to the user session; re-verified on 1.1.12 that agy models inside a fake HOME returns the full list) and false on macOS, where the login keychain is resolved through $HOME. So every antigravity worker started a fresh OAuth flow and died at agy's 60 s authentication timed out, while antigravity_ask — which never touches HOME — kept working. Isolation is now conditional, decided two ways:

  • Proactively, by probing once per process: agy -p "/usage" inside a throwaway isolated HOME. On agy 1.1.11+ that's free (the CLI answers it, no agent turn, no quota), but the quota table comes from your account, so it can't be answered without working credentials. Skipped on Windows, where it can't fail.

  • Reactively, because a probe is a proxy and this one can't be tested on the platform it exists for: any worker that fails with an authentication signature flips the process to serialized mode and retries itself there, so you get an answer even if the probe was wrong or unavailable.

  In serialized mode the antigravity workers run in your real HOME behind the same lock the single-agent tools use — correct everywhere, at the cost of the parallelism (other backends stay parallel; a watched worker shows a note instead of live steps, since the step feed reads the isolated transcript). AGY_BRIDGE_NO_HOME_ISOLATION=1 forces it without a probe. Diagnosed by inspection from the report; not reproduced on a Mac — if you're on macOS, please confirm on #2.

• 🐛 agy 1.1.11 killed the model argument — fixed (#3). agy made agy models machine-readable, turning each line from a bare slug into a tab-separated <slug>\t<human label> record (gemini-3.6-flash-high\tGemini 3.6 Flash (High)). The bridge read the whole line as the slug, so its up-front validation rejected every valid model with an error that listed the very slug it had just refused: unknown agy model 'gemini-3.6-flash-high'; expected one of: gemini-3.6-flash-high<TAB>Gemini 3.6 Flash (High), …. Reproduced end-to-end through antigravity_ask; model was unusable on all three antigravity tools (omitting it still worked — the default model path never touched this code). The parser now keeps the first tab field, which reads both formats, and drops any field containing whitespace (a slug never has a space, so such a line is chatter). Note 1.1.12's changelog advertises --output-format json for the models and agents subcommands, but the shipped binary has no such flag (agy models --output-format json → flags provided but not defined: -output-format), so TSV is what there is to parse. The live slug list is unchanged from 1.1.6, and this suite stayed green through the break because every model test mocked the old format — the new tests pin both formats down. The change is in no changelog entry: the guard test was green on 1.1.10, #3 reports the break on 1.1.11, and it was reproduced here on 1.1.12.

• ✨ antigravity_status now reports your remaining AI Pro quota — for free. agy 1.1.11/1.1.12 answer read-only slash commands in print mode itself: no agent turn, no quota spend, no conversation left behind (1.1.11: /usage, /quota, /credits, /model, /effort, /skills; 1.1.12: /permissions, /hooks, /help, /config, /changelog). The status tool runs agy -p "/usage" and adds a row per model family — quota: Gemini Models [ok] Weekly 100%, Five Hour 100% — flagging a family at 0% as a problem, since every call against it fails until its window resets. Version-gated at 1.1.11 as a safety gate: on older agy the same argv is a prompt, so a diagnostic advertised as free would quietly spend a call. The probe is the one bridge call that deliberately omits --disable-slash-commands (a regression test asserts it), and it degrades to nothing on older agy rather than reporting a false problem.

• 🐛 codex's Windows sandbox refuses every command — and codex answers anyway. Re-verifying the bridge against codex 0.149.1 (from 0.144.1) turned up the worst failure shape there is: one that reports success. Under both read-only and workspace-write, every command codex tried came back rejected: blocked by policy — down to pwd — because the policy engine can't classify the pwsh -Command <...> wrapper codex itself builds. Shell commands are how codex reads files, so it saw nothing of the workspace. It did not say so. Asked for the version in a local pyproject.toml declaring 0.27.0, it ran a web search and answered 1.2.0, a version from an unrelated GitHub repository; a second run said 0.1.0. With the sandbox off, the same prompt answered 0.27.0. Exit 0 and a full -o file every time. Not local: there is no exec policy in this machine's config.toml, and it is open upstream (#40060, #38886).

  The bridge can't fix a CLI that reports success, but it no longer passes the result off as sound: any answer whose run had commands refused now comes back with a visible [agent-intern] WARNING naming the count and the policy. It appends rather than raises on purpose — under read-only a model that tries to write is supposed to be blocked, and that run's answer is perfectly good; what was unacceptable was the silence.

• 🐛 codex_continue was broken outside a git repo — fixed. codex exec resume enforces the trusted-directory check just like a fresh run, and the bridge passed --skip-git-repo-check only on fresh runs, on the reasoning that resume inherits the session's recorded cwd and sandbox. So a continue in a plain directory died with "Not inside a trusted directory and --skip-git-repo-check was not specified" — while the fresh ask that created that very session had just succeeded. It only bit outside a git repo, which is why a green hermetic suite and everyday use inside a project never saw it; the test that covered this argv actively asserted the flag was absent. codex exec resume --help lists it, so the fix is the supported one. Re-verified live: ask then continue in a non-git workspace now both answer.

• ✅ Re-verified copilot on 1.0.80 (from 1.0.69) — eleven releases, nothing to change. The one entry that could have reached this bridge was 1.0.71's "reject malformed --allow-tool and --deny-tool patterns with an error message", since read-only mode is a pair of --deny-tool patterns. Re-verified live on 1.0.80: they still parse, a workspace file read answers, and a write is still refused ("Blocked: I can't write files in this environment", no file created). 1.0.79's BREAKING rename of the sandbox setting allowDevToolCaches → allowDevToolAccess is a config key this bridge never reads.

• ✅ agent_swarm honours sandbox on Antigravity workers — it used to ignore it. Every other backend took a per-task sandbox policy; Antigravity dropped the key on the floor, so {"backend": "agy", "sandbox": "read-only"} was a task that looked fenced and ran with nothing holding it back. Plan mode is the first thing agy has that can honour the request, so "read-only" now maps onto it, "danger-full-access" names the unrestricted posture out loud, and "workspace-write" raises rather than implying a scoping agy cannot do.

  Verified live on 1.1.20 in the parallel isolated-HOME path — the one that builds its own argv rather than going through _run_agy, so it had to be threaded explicitly — with both workers in a single swarm running the same cmd /c echo RAN > <absolute path>: the read-only worker created nothing and returned a plan document, the unfenced one created its file. The version gate and the slash-command guard run at task-normalization time, so a bad plan request fails the whole swarm up front rather than N calls in.

  Two deliberate omissions. An omitted sandbox still leaves an agy worker unrestricted, unlike every other backend: flipping that default would silently turn existing file-writing swarm tasks into plan documents. And schema is not wired into the swarm at all — both Antigravity swarm paths read the answer from the isolated transcript, where structured_output does not exist, so it would mean moving the most load-bearing read path in the swarm onto JSON stdout. The structured-output caveat below is the other half of that reasoning: a schema that follows field order rather than content, run across N parallel workers, is N confidently wrong answers.

• ⚠️ schema returns structured output — and agy fills it in a pass that doesn't re-read the question. Passing a JSON Schema to antigravity_ask / antigravity_continue maps to agy 1.1.8's --json-schema, and the tool returns agy's structured_output — exactly the declared fields, as JSON text you can json.loads. Note the prose response on the same run is not the same thing: it carries the model's raw emission, agy's internal toolAction / toolSummary keys, and sometimes a sentence of prose ahead of the JSON. A run that yields no structured output raises rather than handing you prose to parse.

  The caveat is worth more than the feature. agy populates the schema in a finishing pass that does not reason about the content again, so any field the turn never actually established gets guessed from the shape of the schema. Measured on 1.1.20, classifying "this broke my build and wasted my whole afternoon":

  prompt	schema	result
  plain classify request	enum: ["positive","negative"]	positive — 3 runs out of 4
  plain classify request	same enum, order reversed	negative — 2 of 2
  same, plus a reason field	reason first, then the enum	reason came back "Completed sentiment classification task."
  "state the verdict and why, then report it"	the original, biased enum	negative — 3 of 3

  It was following field order, not the sentence. So use schema to shape an answer the turn has already worked out — extraction, formatting, pulling fields out of something the model just read — and do not delegate the judgment itself to it. Ask for the reasoning in the prompt; the schema is the envelope, not the thinker.

• ✅ Re-verified on agy 1.1.21–1.1.25 — the only drift was the model catalog, and it moved in both directions. Five releases, re-checked live on Windows. Plumbing all held: antigravity_ask round-tripped through the real argv on both the default-model path and an explicit --model, the --output-format json object still carries conversation_id / status / response, agy models still emits <slug>\t<label>, the /usage quota table still parses, and the JSONL transcript read path still resolves. What changed is data, not code:

  • gemini-3.8-flash arrived and took the default (gemini-3.8-flash-{low,medium,high}). Its changelog entry scopes it to "when connecting with a GEMINI_API_KEY", but it is in the catalog on ordinary AI Pro browser auth too, and --model gemini-3.8-flash-high round-tripped clean.

  • The whole gemini-3.5-flash family was dropped, and no changelog entry says so. 1.1.22 was still naming 3.5 Flash in a fix, so this is the same class of silent catalog change as the 1.1.11 TSV break — every 3.5 example in these docs had quietly become a guaranteed rejection.

  Nothing broke, because validation reads the live list rather than a baked-in one; the two guard tests added after the last drift are what fired, one per direction. Two upstream fixes also landed on shapes this bridge depends on, both moving toward it: 1.1.23 fixed subcommands such as models hanging on an inherited, unclosed stdin — the exact hang list_agy_models has always spawned with a closed stdin to dodge — and 1.1.24 fixed headless runs with piped stdout/stderr hanging on exit, which is every call this bridge makes. One false alarm worth knowing: agy leaves an empty conversation directory behind when it self-updates, and antigravity_status reports it as newest transcript [!!]. The read path is fine — the next real call writes a transcript and the row goes green. VERIFIED_AGY_VERSION → (1, 1, 25).

• ✅ Re-verified on agy 1.1.13–1.1.20 — no code change needed, and two upstream fixes moved toward the bridge. Eight releases of drift, re-checked live on Windows: antigravity_ask and antigravity_continue both round-tripped through the real argv (the continue pinned its conversation and recalled a codeword), agy's --output-format json object still carries conversation_id / status / response, agy models still emits <slug>\t<label>, the /usage quota table still parses into per-family rows, and all three version gates (supports_json_output, supports_disable_slash_commands, supports_print_usage) resolve true. The two changes that touch this bridge both make it more correct:

  • 1.1.18 made a valueless -p and a stray trailing argument hard errors. That is precisely the mis-parse the bridge is built to avoid — --print --sandbox 'do the task' used to run with the prompt --sandbox and the sandbox silently off. The bridge already passes the prompt as -p's value and already appends -p last, so nothing changed here except that agy now enforces the rule instead of failing quietly. Re-verified with a prompt whose first character is a dash.

  • Print-mode exit codes got honest, in both directions. 1.1.18 made a dropped agent stream exit non-zero rather than reporting a clean success with an empty response; 1.1.20 stopped treating benign tool errors and permission denials as fatal. The bridge raises on any non-zero exit, so both edits sharpen a signal it was already trusting.

  Also worth knowing, though nothing here had to move: 1.1.13 fixed two long-standing hazards in exactly the code path this bridge falls back to — transcript corruption when a background message appended while context compaction was rewriting it (which left JSON that no longer parsed) and unbounded growth of the on-disk conversation database. That fallback is the bridge's most fragile read path, and it is now sturdier upstream. 1.1.14 and 1.1.20 also shifted agy's default permission posture (workspace reads auto-granted under the default review mode; access outside the workspace narrowed to read-only) — --dangerously-skip-permissions stays load-bearing, so the Security note is unchanged.

  Docs-only drift, now fixed: agy grew the gemini-3.7-flash family and moved the default onto it, so an untouched install runs gemini-3.7-flash-high, not the gemini-3.6-flash-high every doc here named (verified in a throwaway HOME with no settings.json at all). Nothing broke — validation reads the live list — but the guard test only ever noticed a model agy dropped, which is why a whole new family and a moved default sailed through a green suite. A second guard now fails when agy offers a family the docs don't mention. VERIFIED_AGY_VERSION → (1, 1, 20). Not adopted, and not exercised beyond confirming agy still lists them: --json-schema, 1.1.15's --input-format stream-json (one process, many turns), --mode accept-edits|plan, and 1.1.16's agy mcp subcommands. Nothing here needs them today.

• ✅ Re-verified the rest of agy 1.1.11/1.1.12 — nothing else broke. The slash shield still holds: 1.1.11 replaced the silent fall-through for interactive-only commands with an explicit refusal that recommends the exact flag this bridge already passes (agy -p "/clear" → exit 2, "pass --disable-slash-commands to send /clear to the model as literal text"), and antigravity_ask("/clear Reply with the single word BRIDGE…") returned BRIDGE end-to-end. The read-only set is why the shield stays load-bearing — unshielded, a prompt opening with /model would get agy's table instead of an answer. 1.1.12 also stopped swallowing startup diagnostics (including the --conversation not-found warning the continue path can trigger): they go to stderr, so stdout stays a pure JSON result object — verified with a deliberately bogus --conversation (exit 0, clean JSON, warning on stderr). Benign wins: a Windows crash resolving the conversation transcript path is fixed (the artifact watch mode's log_uri points at), headless -p now settles a choice itself instead of stalling on a question nobody can answer (fewer timeouts), and 1.1.11 made retries honor the server's retry delay and stopped an empty credits response reading as "Out of credits". VERIFIED_AGY_VERSION → (1, 1, 12). --effort stays unadopted, now with a harder reason: it isn't universal — --model claude-sonnet-4-6 --effort low fails with "--effort is not supported for model", while the gemini slugs already bake the level in. Everything else (Vim editing mode, artifact-viewer polish, plugin enablement, admin controls and MCP progress callbacks — agy as an MCP client) is off the bridge's path.

• 🛡️ agy 1.1.9 broke print mode for any prompt starting with a slash — fixed by --disable-slash-commands. 1.1.9 made -p expand slash commands and skills instead of sending them to the model as text, so a prompt whose first token names a registered command is executed as that command and never reaches the model. Verified live on 1.1.10 through this bridge: antigravity_ask("/help") came back with agy's own help page, not an answer. That is not just wrong output — agy's registered set includes side-effecting commands (/goal starts an autonomous long-running task, /schedule creates cron jobs), and bridge prompts routinely carry text the caller did not author, so an untrusted string beginning /schedule … would have run it. Every agy argv path now passes --disable-slash-commands (one change in _agy_base_args covers ask, continue, both watched runners, and both swarm workers). Version-gated: the flag doesn't exist before 1.1.9, and neither does the expansion. Prompts starting with a POSIX path (/etc/hosts …) were never affected — they match no command — but that was luck, not a boundary. Set AGY_BRIDGE_ALLOW_SLASH_COMMANDS=1 to keep the expansion if you want -p "/my-skill <args>" to invoke a skill.

• 🐛 Non-ASCII answers were being mangled on Windows — fixed. Every backend emits UTF-8, but the bridge spawned them with bare text=True, which decodes using the locale codepage (locale.getpreferredencoding() — cp1254 on a Turkish Windows, cp1252 elsewhere). Any non-ASCII answer came back corrupted: dosyası arrived as dosyası, exactly 'dosyası'.encode('utf-8').decode('cp1254'). Every bridge plus the swarm workers now decode UTF-8 explicitly with errors="replace", the pattern cursor_bridge.py already used. A regression test asserts no subprocess call reintroduces bare text=True. ASCII-only answers were never affected, which is why this survived so long.

• ✅ Re-verified on agy 1.1.9 and 1.1.10. Beyond the slash-command break above: 1.1.10 fixed --model/--effort being silently ignored in headless -p (they were applied after model configuration had already initialized, so the run fell back to the persisted/default model). The bridge validates and passes --model on every call, so on 1.1.8–1.1.9 the model argument was a no-op even though a typo was still correctly rejected — if you pinned a model in that window, you were served the default. Re-confirmed working on 1.1.10 through the bridge (model="claude-sonnet-4-6" → a Claude answer, not Gemini). No code change was needed for it. 1.1.10 also added a non-blocking advisory banner when the same conversation is open in another CLI instance — the shape antigravity_continue and the swarm can produce — so _parse_json_result now locates the result object instead of requiring stdout to start with {; leading and trailing chatter are both absorbed rather than degrading into a raw JSON blob in your answer. VERIFIED_AGY_VERSION → (1, 1, 10). Nothing else in 1.1.9/1.1.10 reaches the bridge — the rest is interactive-TUI, hooks, auth, and MCP-client work.

• ✅ Verified on agy 1.1.7 and 1.1.8 — nothing broke, and 1.1.8 made the bridge sturdier. 1.1.8 gave print mode an --output-format flag (text | json | stream-json). The existing text path was confirmed live on 1.1.8 first (ask, pinned continue, and --model all clean), then the bridge switched its plain ask/continue calls to --output-format json, because reading a contractual response field beats trusting the layout of bare text. The real prize is the conversation_id agy returns with it: the bridge records it and pins a later antigravity_continue to exactly the conversation it last ran in that workspace, instead of inferring it from last_conversations.json — shared state agy rewrites for every session, including your own interactive TUI work in the same folder. Practical difference: antigravity_continue now resumes the bridge's own thread, where before it could land on a conversation you'd since started in the Antigravity TUI. Older agy is unaffected — the flag is version-gated (pre-1.1.8 has no such flag), and any non-JSON stdout falls back to the previous text path, so a silently-ignored flag degrades instead of crashing. VERIFIED_AGY_VERSION → (1, 1, 8). Not adopted: --json-schema (works; nothing here needs it). Nothing else in 1.1.7/1.1.8 reaches the bridge — the rest is interactive-TUI, plugin-hook, and MCP-client work.

• ✅ Watch mode reads agy's live event stream instead of scraping its transcript. On agy 1.1.8+ the watched runners request --output-format stream-json and consume agy's typed init / step_update / result events straight off stdout. Verified before the rewrite that they arrive incrementally (a 17 s run spread its 18 events over 12.4 s), and confirmed live that a watched run's step count grows while agy works. The stream carries the real command as a nested object (the transcript stored tool args JSON-encoded inside a string), streaming text fragments, and a conversation_id — so a watched run now pins later continues just like a plain one. This retires the timer-based transcript polling, which matters beyond tidiness: agy has announced JSONL is being replaced by SQLite, and watch was the last path that would have broken when it goes. Pre-1.1.8 agy keeps the original transcript path, re-verified live.

• ⚠️ Behavior change: multi-step answers now include the model's narration. agy's response is the whole turn; the old transcript scrape returned only the last planner response. Identical for a single-step ask, different for a chatty multi-step one (one measured run: 297 chars vs 128, the full answer ending in the old one). The full turn is now returned on every path — response is agy's own contract for what the turn produced, and the old last-step rule silently dropped content whenever the model did the work and then closed with a short "Done."

• ✅ Re-verified on agy 1.1.6 — no code change needed. 1.1.6 added the gemini-3.6-flash family to agy models and moved the settings.json default to Gemini 3.6 Flash (High); the default path and --model gemini-3.6-flash-high both round-tripped clean, and the JSONL + SQLite read paths still match agy's unchanged conversation schema. Its one bridge-adjacent fix — print mode now surfacing the real conversation-creation error instead of a misleading "no active conversation" — only improves the diagnostic the bridge already reads on failure. Everything else (Markdown custom agents, /copy and /codesearch polish, background-task hardening) is interactive-TUI or client-side work that doesn't reach the bridge. Docs-only: the model list and default examples now name the 1.1.6 slugs, and the guard test advertises gemini-3.6-flash-high against the live list.

• ⚠️ Verified on agy 1.1.5 — it renamed every model, so old model values now fail. 1.1.5 replaced agy's human-readable model labels with stable slugs, and agy models reports only those: "Gemini 3.1 Pro (High)" is now gemini-3.1-pro-high, and the Claude entries are claude-sonnet-4-6 and claude-opus-4-6-thinking (the mapping is not 1:1 — check agy models, or antigravity_status, for the current list). Since the bridge validates model against agy models, an old label is rejected up front with the valid list — you lose the call, not your money, and never silently run on the wrong model. Pass slugs and you're fine. Nothing in the bridge's machinery needed changing (validation was always format-agnostic — which is exactly why the entire test suite stayed green while every documented example went stale), so this release is docs plus one new test that checks the models we advertise against the live agy models list. Everything else in 1.1.5 is interactive-TUI, MCP-client, or background-task work that doesn't reach the bridge; its new --effort flag is a second axis we don't pass, because the slug already pins the effort variant.

• ✅ Verified on agy 1.1.4 — no code change was needed. 1.1.4 relaxed the 1.1.3 headless gate so that -p now honors your persisted settings.json policies (permissions, file access, sandbox mode, auto-execution, artifact review) instead of blanket-denying. --dangerously-skip-permissions still overrides those policies, so the flag stays load-bearing and stays exactly where it is — re-verified live against a workspace deliberately absent from trustedWorkspaces, with a permissions.allow list naming neither file nor command access: a workspace file read returned the right contents, and a terminal command and a file write both executed. Worth knowing: that flag is now the only thing between a bridge call and your own settings.json policy, and dropping it would get you whatever that file says rather than 1.1.3's deny-everything. 1.1.4 also stopped /btw side-questions from leaking into the conversation list as duplicates carrying the parent's title — that list is what conversation pinning reads, so one way to resume the wrong thread is gone.

• ✅ Verified on agy 1.1.3 — base dir, last_conversations.json (still keyed by workspace path), the brain/.../transcript.jsonl path, the transcript schema, and the -p/-c/--print-timeout flags are all unchanged; a live antigravity_ask + conversation-pinned antigravity_continue round-trip returns clean over stdout and antigravity_status diagnostics pass. 1.1.3 broke and the bridge fixed the one thing that mattered: headless -p no longer auto-approves tool calls, it soft-denies them (print mode cannot prompt), so without a flag even "read pyproject.toml and report the version" returned nothing — exit 0, empty stdout, the reason only on stderr. The bridge now passes --dangerously-skip-permissions on every agy path, which restores file writes, terminal commands and workspace reads (a live bridge round-trip reads this repo's real version again). The flag must precede -p, whose value is the prompt — otherwise the flag becomes the prompt and the task is silently dropped. 1.1.2 also made an unresolvable --model hard-fail in -p instead of silently falling back to the settings.json default (the bridge's validate_model still rejects a typo up front, without spending a call). 1.1.0's execution-mode system (--mode, request-review) remains a no-op for the bridge: -p is spawned with DEVNULL stdin, so that interactive gate never engages. --sandbox behavior is likewise unchanged (blocks the terminal, not file writes). The print-mode stdout path (fixed on 1.0.15, Windows) still applies; the transcript stays the fallback.

• ✅ Verified on codex-cli 0.144.1 — codex exec, -o/--output-last-message, codex exec resume, the --json event stream, and the ~/.codex/sessions/.../rollout-*.jsonl layout the continue path reads are all in place; a live codex_ask round-trip + codex_status pass. (Bumped from the 0.141.0 baseline: flags, session layout and the round-trip all re-verified unchanged.)

• ✅ Verified on copilot 1.0.69 — copilot -p -s (clean stdout answer), --session-id set-then-resume, --model, --output-format json (watch stream), and the ~/.copilot/session-state/<id>/workspace.yaml layout the continue fallback reads are all in place; live copilot_ask / copilot_continue round-trips + a mixed agent_swarm pass. (Bumped from 1.0.68: 1.0.69 adds a --resume convenience flag the bridge doesn't need; --session-id still both sets a fresh id and resumes it — re-verified live, ACK then codeword recall.)

• ✅ Verified on cursor-agent 2026.07.23 — cursor-agent -p --output-format text --trust (clean stdout answer), create-chat + -p --resume <id>, --model (validated against cursor-agent models), --output-format stream-json (watch stream), and the ~/.cursor/chats/<md5(workspace)>/<chat-id>/meta.json layout the continue fallback reads are all in place; live cursor_ask / cursor_continue round-trips + a mixed agent_swarm pass.

  The deferred live round-trip has since been done, on that same 2026.07.23. It had been skipped the first time because the Cursor account was at its usage limit, leaving the run path confirmed only by structure. End-to-end through the bridge now: cursor_ask read a workspace file and answered from it, cursor_continue resumed the pinned chat and recalled it, and a read-only run refused to write — "I'm in Ask mode … I can't create or write files", no file created — so cursor's agent-enforced mode holds in practice and not just in --help. Every model id the docs name still validates against the live list, which has grown from 193 ids to 204 with no CLI release: the catalogue moves on its own, so cursor-agent models stays the only current answer.

• 🖥️ Console-detach — before 1.0.15 agy -p wrote its answer to the controlling terminal, not stdout; under a TUI that text leaked into the host's prompt (seen on 1.0.9). 1.0.15 fixed this on Windows (stdout now carries the answer), but the bridge still spawns agy detached (CREATE_NO_WINDOW / a new POSIX session), which prevents the leak on older/other platforms and is harmless on 1.0.15+.

• 💾 SQLite migration — handled — agy still dual-writes a .db per conversation; on the fallback path, when the JSONL transcript is absent (already true for --sandbox runs, and the announced future default) _read_response falls back to reading the .db, verified to match across 100+ conversations. See the FAQ.

• 🐛 agy stdout bug — fixed on 1.0.15 — -p now prints the clean answer to stdout in a non-TTY subprocess (Windows), so the bridge prefers stdout and only scrapes the transcript when stdout is empty (older agy, non-Windows, or --sandbox). (Codex and Copilot never had this problem — both are stdout-native.)

• 👁️ Watch mode is experimental — pass watch=true to any single-prompt tool to open the Agent Intern window and watch the agent work live (coarse steps; image shown inline). Best-effort and cross-platform; see Watch mode.

• 🔒 Sandbox — agy's --sandbox blocks only shell commands, so it's no boundary and the bridge never passes it. Codex's sandbox is real and enforced — use it; default read-only. Copilot's sandbox is best-effort (tool/path denials, not an OS sandbox); default read-only. Cursor's sandbox is agent-enforced (mode/force; read-only = --mode ask makes write/shell unavailable, not an OS sandbox); default read-only. See Security.

Requirements

• Python 3.10+

• For the Antigravity tools: agy 1.0.0+ on PATH (state-file layout re-verified on 1.0.15; behaviour re-verified on 1.1.25) and an active Antigravity / AI Pro session

• For the Codex tools: codex on PATH and logged in (codex login) — verified on codex-cli 0.149.1 (note its Windows sandbox caveat)

• For the Copilot tools: copilot on PATH and logged in (copilot → /login, or a COPILOT_GITHUB_TOKEN/GH_TOKEN env) — verified on copilot 1.0.80

• For the Cursor tools: cursor-agent on PATH and logged in (cursor-agent login, or a CURSOR_API_KEY env) — verified on cursor-agent 2026.07.23

• For the Grok tools (experimental): grok on PATH and logged in (grok login, or an XAI_API_KEY env) plus a SuperGrok / X Premium+ subscription — flag surface verified on grok 1.0.3, answer path unverified

• For the Kimi tools (experimental): kimi on PATH and logged in (kimi login, or an API key in ~/.kimi-code/config.toml) — flag surface verified on kimi 0.29.1, answer path unverified

Each backend is independent — install only the CLI(s) you plan to use; the other tools simply report "not found" via their *_status tool.

The bridge uses only cross-platform Python (Path.home(), subprocess) and reads paths under ~/.gemini/antigravity-cli/, ~/.codex/, ~/.copilot/, ~/.cursor/, ~/.grok/, and ~/.kimi-code/, which the CLIs write the same way on every OS. Developed and verified on Windows; macOS and Linux should work unmodified provided the CLIs run there. If you test it on those platforms, please open an issue / PR to confirm.

🌐 Community & Acknowledgments

• Qiita (Japan): A huge thanks to @fallout and the Japanese developer community for featuring this project and providing invaluable feedback!

  • Detailed Hybrid Setup Guide (Claude Code × Antigravity CLI)

  • Quick Installation Guide

💡 Path Resolution Fix: Thanks to their community's real-world testing, we identified and resolved a Windows PATH edge case where the MCP server inherits a stale PATH at startup and can't find agy. The AGY_BIN environment-variable fallback was implemented directly inspired by their report!

License

MIT. Do whatever you want with it.