AgentBridge
AgentBridge
Status: Mitte der Migration, und diese README beschreibt den älteren Stand.
AgentBridge begann als Brücke von Claude Code zu Codex/Antigravity, und alles, was unten dokumentiert ist, funktioniert heute. Es wird generalisiert, sodass jede unterstützte CLI der Orchestrator sein kann und jede andere ein Worker, mit Routing, das von einem Benutzerprofil gesteuert wird, statt von hartcodierten Modellnamen.
Wie es weitergeht, steht in
docs/architecture.mdunddocs/roles.md. In Arbeit: eine Provider-Adapter-Schicht (src/providers/), ein Routing-Profil (src/profile/) und einagentbridge init-Setup-Ablauf. Der Cursor-Adapter ist vorhanden, aber unverifiziert — seine Flags wurden aus bisherigem Wissen geschrieben, statt von einer installierten CLI abgelesen, und genau das steht oben in der Datei.Bis die Migration abgeschlossen ist, behandle die Abschnitte unten als zutreffend für Codex- und Antigravity-Worker und die Doku als zutreffend für das Design.
Orchestratoren
AgentBridge stellt seine /agentbridge …-Befehlsschnittstelle als MCP-Prompts bereit,
sodass jeder MCP-Client, der prompts/list unterstützt, dieselben Befehle direkt vom
Server erhält — keine host-spezifischen Befehlsdateien, die installiert oder synchron
gehalten werden müssten.
Host | Installation | Befehle |
Codex CLI | über MCP-Prompts, plus | |
Claude Code | MCP-Server registrieren, dann optional | über MCP-Prompts |
Befehl | Funktion |
| Arbeit abschätzen, planen, delegieren, verifizieren, berichten |
| CLIs erkennen, nachweisen, dass jede funktioniert, Routing-Profil schreiben |
| was installiert ist und wie Rollen abgebildet werden; keine Inferenz |
| mit echten Smoke-Jobs diagnostizieren und sagen, was zu beheben ist |
| Routing anzeigen oder neu ableiten, optional für eine Rolle |
| eine abgegrenzte Repository-Untersuchung |
| unabhängiges Review durch eine andere Modellfamilie |
| einen unterbrochenen Lauf fortsetzen |
Die Doktrin hinter diesen Befehlen liegt in doctrine/ und nennt keine
Modelle — sie routet nach Rolle, und .agentbridge/profile.json bildet
Rollen auf das ab, was der Benutzer tatsächlich installiert hat.
Ein kleiner lokaler stdio-MCP-Server, der es Claude Code ermöglicht, Arbeit an die
Codex-CLI und die Antigravity-CLI (agy) als externe Worker zu delegieren —
unter Verwendung der CLI-Sitzungen, in denen du bereits angemeldet bist, ohne
API-Keys.
Claude bleibt der Orchestrator. AgentBridge ist bewusst schlichte Verrohrung: Es verwandelt Claudes strukturierte Anfrage in einen Worker-Prompt, führt die CLI aus und gibt ein kompaktes, strukturiertes Ergebnis zurück.
User
└─> Claude Code (orchestrator — decides what to delegate)
└─> AgentBridge MCP tool (codex_run / antigravity_run)
└─> codex exec | agy --print
└─> result
<─ structured MCP result
<─ Claude inspects the work and continuesRelated MCP server: agent-intern
Was es nicht ist
Kein Cloud-Dienst, keine Web-UI, keine Datenbank, kein Daemon, kein Dashboard, keine Job-Warteschlange, kein Kontosystem und keine API-Key-Verwaltung. Es ist ein einziger Node-Prozess, den Claude Code über stdio startet und beim Beenden stoppt.
So funktioniert es
Claude ruft
codex_runoderantigravity_runmit einer strukturierten Anfrage auf (goal, mode, model, effort, paths, contract, acceptance criteria…).AgentBridge setzt aus genau diesen Feldern einen Worker-Prompt zusammen. Es führt kein eigenes Modell aus — das ist String-Zusammenbau, keine Inferenz.
Es reserviert Schreibbereiche, erstellt einen Snapshot des git-Arbeitsbaums und startet die CLI mit einem Argument-Array (
shell: false).Es parst die maschinenlesbare Ausgabe der CLI, extrahiert das endgültige Ergebnis des Workers (niemals dessen interne Überlegungen), erstellt einen Diff des git-Baums, um festzustellen, was sich tatsächlich geändert hat, und gibt ein kompaktes JSON-Ergebnis zurück.
Ein MCP-Aufruf = ein Worker-Versuch. AgentBridge wiederholt nie. Ob ein weiterer Versuch sinnvoll ist, entscheidet Claude.
Anforderungen
Node.js | ≥ 20.10 (gebaut und verifiziert auf 24.14) |
Codex CLI | auf |
Antigravity CLI |
|
git | optional, aber dringend empfohlen; ohne git können |
AgentBridge liest, kopiert, exportiert oder verändert niemals deine Codex- oder Antigravity-Anmeldedaten. Es ruft die CLIs genau so auf, wie es ein angemeldeter Mensch tun würde.
Installation und Build
npm installnpm run buildnpm testDie Testsuite verwendet durchgehend gemockte Prozesse, sodass ein normales npm test
kein Modellkontingent verbraucht.
Bei Claude Code registrieren
Einmal auf Benutzerebene registrieren, damit jedes Projekt es verwenden kann:
claude mcp add --transport stdio --scope user agentbridge -- node D:\Code\Agentbridge\dist\index.jsVon einem Terminal aus verifizieren:
claude mcp listclaude mcp get agentbridgeDann von innerhalb von Claude Code verifizieren, indem du /mcp ausführst. Du
solltest agentbridge als verbunden aufgelistet sehen, mit drei Tools: codex_run,
antigravity_run, bridge_status. Bitte Claude, bridge_status aufzurufen, um einen
vollständigen Gesundheitsbericht zu erhalten.
Wenn du AgentBridge neu baust, starte Claude Code neu (oder verbinde den Server über
/mcp neu), damit es das neue dist/ übernimmt.
Projektverzeichnis
Worker laufen in einem einzigen Projektverzeichnis und sind darauf beschränkt; es wird in dieser Reihenfolge aufgelöst:
AGENTBRIDGE_PROJECT_DIR, dann das bisherigeCLAUDE_PROJECT_DIR(das Claude Code exportiert).Das erste
file://-Wurzelverzeichnis, das der MCP-Client bekannt gibt.Das Arbeitsverzeichnis des Serverprozesses.
bridge_status berichtet, welches verwendet wurde.
Tools
codex_run
Feld | Typ | Hinweise |
| string | erforderlich |
|
| erforderlich |
|
| erforderlich |
|
| erforderlich |
| string[] | Dateien, die zuerst angesehen werden sollen |
| string[] | erforderlich im Modus |
| string[] | Pfade, die der Worker nicht verändern darf |
| string | Hintergrundwissen, das das Repo nicht enthält |
| string | Schnittstellen/Typen, die exakt eingehalten werden müssen |
| string[] | |
| string[] | Kontext für den Worker — AgentBridge führt diese selbst nie aus |
| number | Standard 900, begrenzt auf 30–3600 |
Modelle. Drei Slugs sind adressierbar, und jeder wird unverändert an die CLI übergeben:
| Was es ist |
| stärkstes allgemeines Engineering-Modell |
| Spezialist für tiefes Brownfield / bestehende Codebasen |
| wirtschaftliches Arbeitstier für hohe Volumina |
Effort-Mapping (Orchestrator-Bezeichnung → Codex model_reasoning_effort):
|
|
|
|
|
|
|
|
|
|
Das Mapping ist vollständig und deterministisch. Die ultra-Stufe von Codex ist bewusst
nicht bereitgestellt: Nur einige Modelle bieten sie an, und eine sechste Bezeichnung, die
für zwei von drei Modellen funktioniert, würde das Routing modellabhängig machen.
Verfügbarkeit. Vor dem Start prüft AgentBridge das angeforderte Modell und den
Effort gegen den eigenen Modellkatalog der Codex-CLI (models_cache.json in
CODEX_HOME) — ein Dateizugriff, keine Inferenz.
Modell gelistet, Effort gelistet → der Auftrag läuft
Modell gelistet, Effort nicht →
invalid_effort, mitdetails.supported_effortsModell nicht gelistet →
requested_model_unavailable, mitdetails.available_modelskein lesbarer Katalog → der Auftrag läuft trotzdem, mit einer Warnung, dass die Verfügbarkeit
unverifiedwar
Es wird niemals etwas durch etwas anderes ersetzt. Eine Routing-Entscheidung, die nicht erfüllt werden kann, wird als strukturierter Fehler zurückgegeben, der genügend Metadaten für ein einstufiges Umrouting enthält, statt als stillschweigend schwächeres Modell.
Der aufgebaute Aufruf lautet:
codex exec --json --skip-git-repo-check -m <MODEL> -c model_reasoning_effort="<EFFORT>" \
-s <read-only|workspace-write> -C <PROJECT> -o <tmpfile> --color neverwobei der Prompt über stdin gestreamt wird. Modell, Effort und Sandbox werden bei
jedem Aufruf übergeben, sodass ein Lauf niemals das erbt, was gerade in
~/.codex/config.toml gesetzt ist.
analyze und review verwenden die echte read-only-Sandbox von Codex —
Schreibzugriffe werden tatsächlich verhindert, nicht nur abgeraten.
antigravity_run
Gleiches Schema, mit:
Feld | Typ | Hinweise |
|
| erforderlich |
|
| optional, standardmäßig |
Logische Namen werden zur Laufzeit gegen die aktuelle agy models-Liste aufgelöst:
Bezeichnung | Effort | Wird aufgelöst zu (auf diesem Rechner) |
|
|
|
|
|
|
|
|
|
Antigravity kodiert die Reasoning-Stufe in der Modell-ID, sodass model + effort zu
einer einzigen ID aufgelöst werden und kein separates --effort-Flag gesendet wird —
die beiden können nie widersprüchlich sein. Flash hat nur diese drei Stufen: extra high und max geben invalid_effort zurück, statt stillschweigend eine schwächere
Stufe auszuführen, als du angefordert hast.
Antigravity ist absichtlich auf die günstige Gemini-Stufe beschränkt. Die
Claude-Modelle, die agy ebenfalls anbietet, werden nicht als routbare
Bezeichnungen bereitgestellt — für Reasoning auf Claude-Niveau verwende Claude Code
selbst oder Codex, die echtes Sandboxing und (bei Codex) wählbaren Effort bieten.
Das Label hat eine geordnete Kandidatenliste von IDs für dasselbe Modell. Wenn keines davon von der installierten CLI angeboten wird, schlägt der Aufruf mit requested_model_unavailable und der vollständigen Liste verfügbarer Modelle fehl. Es fällt niemals stillschweigend auf ein anderes Modell zurück. Die aufgelöste ID wird bei jedem Lauf in warnings zurückgemeldet.
Der erzeugte Aufruf ist:
agy --print <PROMPT> --model <RESOLVED_ID> --output-format json \
--mode <plan|accept-edits> --add-dir <PROJECT> \
--dangerously-skip-permissions --print-timeout <N>s--disable-slash-commands wird nur für implement-Läufe hinzugefügt: Die CLI ignoriert --mode plan, wenn die Slash-Command-Erweiterung deaktiviert ist, sodass das Senden beider stillschweigend das einzige No-Write-Verhalten verwerfen würde, das Antigravity bietet.
bridge_status
Keine Argumente. Verbraucht keine Modellinferenz – es führt nur --version-Sonden, agy models, ein git rev-parse und eine Lektüre des Modell-Caches der Codex-CLI aus.
Gibt zurück:
AgentBridge-Version, Projektverzeichnis (und wie es aufgelöst wurde), Node/Plattform
git_verification– ob git-basiertefiles_changed/scope_violationshier überhaupt funktionieren. Wenn nicht, ist ein leeresscope_violationsStille, kein sauberes Gesundheitszeugnis, und die Warnungen sagen dascodex.installed/version/path/authcodex.model_status– pro Modell:available|unavailable|unverified, die AgentBridge-Effort-Labels, die es akzeptiert, und die rohen Reasoning-Ebenen der CLIcodex.model_source– woher die Verfügbarkeit stammt und wie frisch sie istantigravity.installed/version/path/auth, erkannte Modelle, wie jedes logische Label + Tier aufgelöst wurde, undmodel_statusin derselben Drei-Zustands-Formantigravity.unsupported_efforts– die Orchestrator-Labels, die Flash nicht übernehmen kannaktive Jobs und ihre Schreibbereiche
Warnungen
Verfügbarkeit wird nie geraten. Wenn die installierte CLI keinen billigen Beweis bietet, ist der Status unverified statt einer Behauptung in die eine oder andere Richtung.
Es gibt niemals Anmeldedaten oder Umgebungsvariablen zurück.
Ergebnisformat
{
"status": "success",
"provider": "codex",
"model": "gpt-5.6-luna",
"effort": "high",
"mode": "implement",
"duration_ms": 12345,
"exit_code": 0,
"summary": "...",
"files_changed": ["src/upload.ts"],
"scope_violations": [],
"tests_or_checks_run": ["npm test -- upload"],
"test_results": "12 passed",
"concerns_or_blockers": [],
"stderr_tail": "",
"warnings": []
}effort ist für beide Anbieter vorhanden – die Codex-Reasoning-Ebene oder die Flash-Stufe, die die Modell-ID kodiert. files_changed und scope_violations werden von AgentBridge aus git berechnet, nicht vom Wort des Arbeiters übernommen. Internes Reasoning wird verworfen. summary ist auf 16 000 Zeichen begrenzt, wobei Kopf und Ende erhalten bleiben und summary_truncated: true gesetzt wird, wenn es abgeschnitten wird.
Fehler
Fehler geben dieselbe Hüllenform zurück mit status: "failed", einer error-Kategorie, einer umsetzbaren message und – wo verfügbar – exit_code, stderr_tail und einem details-Objekt.
Category | Meaning |
|
|
| die CLI meldete ein Anmeldeproblem – melde dich selbst erneut an |
| das angeforderte Modell wird nicht angeboten; es wurde kein Ersatz vorgenommen |
| Effort-Label außerhalb der fünf unterstützten Werte |
| z. B. |
| ein anderer aktiver Worker besitzt bereits überlappende Schreibpfade |
| ein angegebener Pfad hat das Projektverzeichnis verlassen, oder der Worker hat außerhalb seines Bereichs geschrieben |
| der Worker hat die Zeit überschritten; sein Prozessbaum wurde beendet |
| Nicht-Null-Exit oder eine Nicht- |
| die maschinenlesbare Ausgabe der CLI konnte nicht geparst werden |
Beispiele für Claude-Aufrufe der Worker
Günstige, schnelle Analyse:
{ "tool": "codex_run",
"goal": "Explain how session refresh works and where it can race.",
"mode": "analyze", "model": "gpt-5.6-luna", "effort": "light",
"relevant_files": ["src/auth/session.ts"] }Anspruchsvolle Implementierung, maximales Reasoning, eng begrenzt:
{ "tool": "codex_run",
"goal": "Make the uploader retry 502s with exponential backoff.",
"mode": "implement", "model": "gpt-5.6-sol", "effort": "max",
"allowed_paths": ["src/upload.ts", "tests/upload.test.ts"],
"no_touch": ["src/auth"],
"contract": "export function upload(f: File): Promise<Result>",
"acceptance_criteria": ["Retries up to 3 times", "Existing callers unchanged"],
"tests": ["npm test -- upload"] }Zwei Codex-Worker mit disjunkten Bereichen – diese laufen parallel:
{ "tool": "codex_run", "mode": "implement", "model": "gpt-5.6-sol",
"effort": "high", "allowed_paths": ["src/api"], "goal": "..." }
{ "tool": "codex_run", "mode": "implement", "model": "gpt-5.6-luna",
"effort": "medium", "allowed_paths": ["src/ui"], "goal": "..." }Antigravity für günstige mechanische Arbeit:
{ "tool": "antigravity_run", "goal": "Summarise every exported symbol in src/lib.",
"mode": "analyze", "model": "Gemini Flash 3.7", "effort": "light" }
{ "tool": "antigravity_run", "goal": "Build the settings page from design.png.",
"mode": "implement", "model": "Gemini Flash 3.7", "effort": "high",
"allowed_paths": ["src/pages/settings"] }Nebenläufigkeit und Dateibereich
implementerfordertallowed_paths. Pfade werden gegen das Projektverzeichnis normalisiert; alles, was es verlässt (.., andere Laufwerke, absolute Pfade anderswo), wird abgelehnt, bevor ein Prozess startet.Aktive
implement-Jobs halten ihre Schreibbereiche im Speicher. Ein neuer Job, dessen Bereiche sich mit einem aktiven überschneiden, wird mitscope_conflictabgelehnt. Disjunkte Bereiche laufen parallel – unzusammenhängende Arbeit wird nie serialisiert.analyzeundreviewreservieren nichts: Sie blockieren nie und werden nie blockiert.
V1-Einschränkung: Erkennung, nicht Isolierung
Dateibereichsschutz erkennt und meldet Verstöße; er sandkastet nicht jeden Worker in seinen eigenen Baum. Ein Codex-implement-Worker läuft mit workspace-write über das gesamte Projekt, sodass er kann außerhalb seiner allowed_paths schreiben – AgentBridge listet jede solche Datei in scope_violations auf, stuft den Status von success herab und sagt es dir deutlich.
Es wird nie automatisch etwas zurückgesetzt. Das Zurücksetzen einer Datei, die bereits vor dem Start des Workers geändert wurde, würde deine (oder Claudes) vorhandene Arbeit zerstören. Erkennung plus ehrliche Berichterstattung ist der V1-Vertrag; Git-Worktree-Isolierung ist bewusst nicht im Umfang enthalten.
Die Zuordnung ist vorsichtig mit dem vorherigen Zustand: Dateien, die vor einem Lauf bereits geändert waren und danach byte-identisch sind, werden dem Worker nie angelastet. Der Vergleich verwendet Porzellan-Status plus Inhalts-Hashing, und committete Dateien werden über einen HEAD-Verschiebungs-Diff erfasst.
Sicherheit
Prozesse werden mit Argument-Arrays und
shell: falseerzeugt – niemals mit einer interpolierten Befehlszeichenkette. Shell-Metazeichen in Argumenten bleiben wörtlich.Windows-
.cmd/.ps1-Launcher (die Node ohne Shell nicht starten kann) werden zu ihrem echten Node-Einstiegsskript aufgelöst und alsnode <script>ausgeführt, sodassshell: truenie benötigt wird.Prompts gehen über stdin an Codex; übergroße Antigravity-Prompts werden in eine temporäre Datei geschrieben und per Pfad referenziert. Keines kann das Windows-32-767-Zeichen-Kommandozeilenlimit erreichen.
testsist Kontext für den Worker. AgentBridge führt es nie aus, und es gibt kein MCP-Argument, das zu einem Befehl wird, den AgentBridge ausführt.Pfad-Traversal außerhalb des Projektverzeichnisses wird abgelehnt.
Timeouts töten den gesamten Prozessbaum:
taskkill /T /Funter Windows und unter POSIX ein SIGTERM an die Prozessgruppe, das nach einer 3-Sekunden-Gnadenfrist zu SIGKILL eskaliert. Die Eskalation überlebt bewusst den direkten Kindprozess, da genau dann Nachkommen noch laufen können. Dies ist Best-Effort – Node stellt kein Windows-Job-Objekt bereit. Wenn alsotaskkillselbst nicht starten kann, ist nur das direkte Kind erreichbar.Ausgabepuffer sind begrenzt (8 MB pro Stream) und UTF-8 wird erst nach dem Wiederzusammensetzen dekodiert, sodass Mehrbyte-Zeichen nie geteilt werden.
Protokolle erfassen nur Job-Metadaten. Nie Tokens, nie die Umgebung, und Prompts/Ausgaben nur bei
AGENTBRIDGE_DEBUG=1.Wovor AgentBridge dich nicht schützt: Der Worker ist ein echter Codierungsagent, der mit deinen Berechtigungen läuft. Im
implement-Modus kann er über seine eigene Tooling Repository-Befehle ausführen. Lege deineallowed_pathsentsprechend fest.
Verifizierung
AgentBridge führt nach dem Beenden eines Workers die eigenen Prüfungen des Projekts selbst aus, außerhalb jeder Sandbox, und gibt die echte Ausgabe in verification zurück:
"verification": [
{ "command": "npm run typecheck", "ok": true, "exit_code": 0, "timed_out": false, "duration_ms": 4120, "output_tail": "..." },
{ "command": "npm run test", "ok": false, "exit_code": 1, "timed_out": false, "duration_ms": 8830, "output_tail": "..." }
]verify_commands– führen Sie genau diese aus, in jedem Modus.In implement-Modus weggelassen – AgentBridge liest
package.jsonund führt die Skriptetypecheckundtestaus, falls sie existieren. Es führtbuild,devoderstartnie von sich aus aus; fragen Sie explizit danach.skip_verification: true– nichts ausführen und sich auf das Konto des Workers verlassen.
Befehle laufen ohne Shell, sodass |, &&, ;, > und Backticks außerhalb von Anführungszeichen abgelehnt statt halb ausgeführt werden. Ein fehlgeschlagener Check setzt error: "verification_failed" und stuft ein success auf partial herab, sodass ein Worker, der grüne Tests behauptet, die Tests selbst nicht übertrumpfen kann.
tests_or_checks_run und test_results berichten, was AgentBridge tatsächlich ausgeführt hat, wann immer eine Verifizierung stattfand; sie fallen nur dann auf die eigenen Behauptungen des Workers zurück, wenn dies nicht der Fall war.
Da die Befehle aus dem Repository stammen, kann ein Brief, der den falschen Runner nennt, AgentBridge nicht dazu bringen, ihn auszuführen: Ein Repository, dessen Testskript node --import tsx --test ist, wird damit geprüft, egal was der Brief sagte.
Umgebungsvariablen
Variable | Purpose |
| Projektverzeichnis; hostneutral, bevorzugt |
| Legacy-Name, weiterhin berücksichtigt; von Claude Code gesetzt |
| bereinigte Prompts und Ausgaben protokollieren |
| Protokollspeicherort (Standard |
| expliziter Pfad zur Codex-CLI |
| expliziter Pfad zur |
| Codex-Sandbox-Richtlinie festlegen: |
| Windows-Sandbox-Backend (Standard |
AGENTBRIDGE_CODEX_SANDBOX=auto verwendet read-only für analyze/review und workspace-write für implement – außer dass ein sandboxierter Codex-Worker unter Windows die Ausgabe eines Unterprozesses nicht erfassen kann (spawn EPERM bei gepiptem stdio), was npm-Skripte, Testrunner und Bundler alle tun – er kann also lesen und bearbeiten, aber nie einen Testrunner, Typprüfer oder Build ausführen. Das ist eine Codex-Einschränkung ohne Konfigurationsknopf, daher fallen implement-Jobs auf danger-full-access zurück, sobald eine einmalige Sonde dies bestätigt, und sagen es in warnings. Analyze und review behalten ihre erzwungene read-only-Grenze. Unter Windows, wenn ein Lauf mit dem defekten Sandbox-Helfer fehlschlägt (helper_unknown_error: apply deny-read ACLs), versucht AgentBridge diesen Job einmal mit danger-full-access, merkt sich das Urteil für den Rest des Prozesses und fügt jedem betroffenen Ergebnis eine Warnung hinzu, dass die Grenze nicht durchgesetzt wurde. Nichts anderes löst diesen Fallback aus, und ein Neustart von AgentBridge versucht die echte Sandbox erneut – eine behobene Codex-Version stellt sie also automatisch wieder her. macOS und Linux sondieren, wiederholen oder fallen nie zurück.
Protokolle sind eine JSON-Zeile pro Job: Zeitstempel, Job-ID, Anbieter, Modell, Effort, Modus, Projekt, Dauer, Exit-Code, Fehlerkategorie.
Fehlerbehebung
executable_not_found – die CLI ist nicht im PATH, den Claude Code an untergeordnete Prozesse exportiert. Bestätigen Sie mit codex --version / agy --version in derselben Shell oder setzen Sie AGENTBRIDGE_CODEX_BIN / AGENTBRIDGE_AGY_BIN.
authentication_required – Ihre CLI-Sitzung ist abgelaufen. Beheben Sie es in einem Terminal: codex login für Codex oder melden Sie sich erneut mit agy an. AgentBridge hat bewusst keine Möglichkeit, dies zu reparieren: Es berührt keine Anmeldedaten.
requested_model_unavailable — die Modelliste hat sich geändert, oder die installierte CLI
hat dieses Modell nie angeboten. Führe bridge_status (oder agy models) aus, um zu sehen,
was tatsächlich angeboten wird. Die Fehlerdetails enthalten diese Information bereits.
AgentBridge schlägt hier absichtlich fehl, anstatt stillschweigend ein anderes Modell
auszuführen. Wenn ein Anbieter eine Modell-ID umbenannt hat, füge die neue ID zu der
entsprechenden Liste in src/models/antigravity.ts (bzw. CODEX_MODELS in
src/models/codex.ts) hinzu und baue neu.
output_parse_failed — die CLI hat ihr maschinenlesbares Ausgabeformat geändert.
Prüfe details.stdout_head im Ergebnis und vergleiche es mit
parseCodexEvents / parseAgyOutput.
Nach einem CLI-Update — führe die Tests erneut aus, dann den Live-Check:
SMOKE_LIVE=1 node scripts/smoke.mjsDieser startet eine echte MCP-Sitzung und führt die günstigste Konfiguration jedes
Workers aus. Ohne SMOKE_LIVE=1 wird nur der Handshake durchgeführt und
bridge_status aufgerufen, was keine nennenswerten Kosten verursacht.
files_changed ist immer leer — das Projektverzeichnis liegt nicht in einem
Git-Arbeitsbaum. Die Warnung im Ergebnis weist darauf hin. Für die Änderungsprüfung
wird Git benötigt.
Unter /mcp erscheint nichts — prüfe, ob der registrierte Pfad auf
dist/index.js zeigt (nicht auf src/), und starte Claude Code nach einem
Neubuild neu.
Layout
src/
index.ts stdio entry point
server.ts MCP server, tool schemas, dispatch
config.ts project-dir resolution, timeout clamping
logging.ts JSONL job log (stderr only, never stdout)
parse.ts worker-envelope parsing, summary capping
types.ts
cli/
resolve.ts PATH lookup + Windows shim unwrapping
detect.ts version probes, agy model listing, auth heuristics
codex-catalogue.ts zero-inference Codex model availability + effort capability
codex-sandbox.ts sandbox policy decision and helper-failure detection
models/
codex.ts effort map, argv construction
antigravity.ts logical→real model resolution, argv construction
process/
runner.ts shell-free spawn, bounded output, tree kill
prompts/
worker-prompt.ts structured request → worker prompt
scope/
paths.ts normalisation, traversal rejection, overlap
locks.ts in-memory write-scope registry
git-state.ts snapshot/diff file attribution
tools/
codex.ts antigravity.ts status.ts common.ts
tests/ 252 tests, mocked processes, no quota used
scripts/smoke.mjs real MCP end-to-end checkAvailable Tools
3 toolsantigravity_runA
Delegate a task to the Antigravity CLI (agy) running as an external worker, using your existing Antigravity login (no API key). The logical model name and effort tier are resolved against the installed CLI's live model list and are never silently substituted. Returns the worker's final result plus git-verified files_changed and scope_violations. One call = one attempt; AgentBridge never retries on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What the worker must accomplish. Be specific and self-contained. | |
| mode | Yes | analyze/review are read-only investigations; implement makes changes and runs checks. | |
| model | Yes | Antigravity model to run. | |
| tests | No | Tests or checks the worker should run. Context for the worker only — use `verify_commands` for anything AgentBridge should execute. | |
| effort | No | Flash reasoning tier, selected via the model id. light=search/extraction/docs/simple edits, medium=default coding, debugging, review, refactors, high=hard reasoning, architecture, visual/multimodal work. Defaults to medium. 'extra high' and 'max' do not exist here — route those to Codex. | |
| context | No | Background the worker needs but cannot infer from the repository. | |
| contract | No | Interfaces, types, or API shapes the worker must conform to exactly. | |
| no_touch | No | Project-relative paths the worker must not modify. | |
| allowed_paths | No | Project-relative paths the worker may write. Required in implement mode; overlapping scopes across concurrent implement jobs are rejected. | |
| relevant_files | No | Project-relative files the worker should look at first. | |
| timeout_seconds | No | Wall-clock limit for the worker process. Default 900s, clamped to 30-3600s. | |
| acceptance_criteria | No | Conditions that must hold for the job to be considered done. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and does an excellent job: it discloses authentication requirements ('using your existing Antigravity login (no API key)'), resolution behavior ('never silently substituted'), return contents ('git-verified files_changed and scope_violations'), and retry policy ('AgentBridge never retries on its own'). No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four sentences, each earning its place: delegation mechanism, resolution policy, return value summary, and retry semantics. It is front-loaded with the primary action and free of redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 12 parameters, no output schema, and no annotations, the description covers key operational context: auth, resolution, returns, and retry policy. It lacks guidance on when to prefer this over codex_run and what happens if the CLI is unavailable, but the 100% schema coverage compensates for parameter-level details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description does not add new parameter-level semantics beyond what the schema already provides; it only references the model/effort resolution vaguely, which is adequately covered in the parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Delegate a task to the Antigravity CLI (`agy`) running as an external worker.' It specifies the verb, resource, and distinctive auth behavior (no API key). However, it does not explicitly differentiate from sibling tools like codex_run, even though the Antigravity-specific naming implies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (codex_run, bridge_status). It mentions 'One call = one attempt' and 'never retries' as behavioral facts, but does not state usage conditions, prerequisites, or when to choose a different tool. Relevant routing advice (e.g., 'extra high' → Codex) is buried in the parameter descriptions, not the main description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
bridge_statusA
Report AgentBridge health: version, project directory, whether git-based scope verification will work here, whether the Codex and Antigravity CLIs are installed, their versions and sign-in state, per-model availability (available | unavailable | unverified) and the efforts each model accepts, resolved Antigravity model ids, active jobs, and warnings. Consumes no model inference — availability comes from each CLI's own catalogue, and is reported as unverified rather than guessed when it cannot be established cheaply. Never returns credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations provided, the description fully carries the transparency burden and excels: it discloses a no-inference cost guarantee, an explicit epistemic honesty policy ('reported as unverified rather than guessed'), and a security guarantee ('Never returns credentials'). These behavioral traits go well beyond what the empty schema reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three prior sentences, each earning its place: scope, then cost/accuracy behavior, then security. The second sentence is list-heavy but necessary since no annotations or output schema exist — the description is the sole documentation. Slightly long but never wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity 0-param, read-only tool with no annotations and no output schema, the description is the only source of truth and covers all critical operations: exact contents of the report, inference cost (none), accuracy semantics (unverified vs guessed), and credential safety (never). Nothing material is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the baseline of 4 per the rubric applies. The description adds no conflicting param info; the only implied input is the health-report scope itself, which is irrelevant for a no-arg call. No compensation needed for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a specific verb+resource ('Report AgentBridge health') and exhaustively enumerates the report's scope: version, directory, CLIs, model availability, model ids, jobs, warnings. This specificity clearly delineates it from siblings codex_run/antigravity_run, which are execution-oriented, making the health/introspection function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The health/introspection framing implies pre-flight or diagnostic use (checking sign-in state, git verification, per-model availability) with clear context. However, no explicit exclusions or named alternatives appear in the description; sibling distinction is inferred from context rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
codex_runA
Delegate a task to the Codex CLI running as an external worker, using your existing Codex login (no API key). Model and reasoning effort are chosen per call and never inherited from global Codex config. Returns the worker's final result plus git-verified files_changed and scope_violations, and — unless skipped — a verification block holding the real output of the project's checks, which AgentBridge runs itself. One call = one attempt; AgentBridge never retries on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | What the worker must accomplish. Be specific and self-contained. | |
| mode | Yes | analyze/review are read-only investigations; implement makes changes and runs checks. | |
| model | Yes | Codex model to run, passed to the CLI verbatim. gpt-5.6-sol is the strongest general engineering model, gpt-5.6-terra the deep brownfield/existing-codebase specialist, gpt-5.6-luna the economical high-volume workhorse. Availability is checked against the installed CLI's own model catalogue; an unavailable model fails with requested_model_unavailable and is never substituted. | |
| tests | No | Tests or checks the worker should run. Context for the worker only — use `verify_commands` for anything AgentBridge should execute. | |
| effort | Yes | Reasoning effort: light->low, medium->medium, high->high, 'extra high'->xhigh, max->max. | |
| context | No | Background the worker needs but cannot infer from the repository. | |
| contract | No | Interfaces, types, or API shapes the worker must conform to exactly. | |
| no_touch | No | Project-relative paths the worker must not modify. | |
| allowed_paths | No | Project-relative paths the worker may write. Required in implement mode; overlapping scopes across concurrent implement jobs are rejected. | |
| relevant_files | No | Project-relative files the worker should look at first. | |
| timeout_seconds | No | Wall-clock limit for the worker process. Default 900s, clamped to 30-3600s. | |
| verify_commands | No | Commands AgentBridge runs itself in the project directory after the worker exits, e.g. ["npm run typecheck", "node --import tsx --test"]. Their real output comes back in `verification`. Run without a shell, so no pipes, redirection, or `&&`. Omitted in implement mode, AgentBridge derives them from the project's own `typecheck` and `test` scripts. | |
| skip_verification | No | Set true to skip AgentBridge's own checks for this job. The result then carries only the worker's account of whether the change works. | |
| acceptance_criteria | No | Conditions that must hold for the job to be considered done. | |
| verify_timeout_seconds | No | Wall-clock limit for each verification command. Default 300s. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behaviors: authentication via existing login, per-call model/effort choices, git-verified files_changed and scope_violations, the verification block auto-run by AgentBridge, skip_verification semantics, and the no-retry policy. It also mentions error behavior (requested_model_unavailable) in schema but the main description adds substantial context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds value, covering purpose, authentication, behavioral semantics, and verification details. It is front-loaded with the core action and flows logically. Slightly long but appropriate for a 15-parameter tool; no fluff detected.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 params, no output schema), the description is remarkably complete. It explains the verification process, git-verified outputs, retry behavior, and model availability handling. It does not detail return value structure, but since there is no output schema, the description covers the essential outcomes (result, files_changed, scope_violations, verification block) sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific meaning beyond what schema provides; it does note that model is passed verbatim and verification runs without a shell, but these are already in schema descriptions. No extra compensation needed, but also no significant enhancement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool delegates a task to the Codex CLI external worker, specifying the resource (Codex CLI) and the verb (Delegate). It distinguishes from siblings by naming Codex explicitly, and includes details like 'no API key' and 'one call = one attempt' that set it apart from antigravity_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus antigravity_run or bridge_status. It mentions configuration behavior (model/effort per call, no global inheritance) and retry policy, but fails to state conditions for selecting this tool over alternatives. This is a gap given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v1.0.0- First observed
antigravity_run - First observed
bridge_status - First observed
codex_run
TDQS
Scored across 3 tools
Each tool has a clearly distinct purpose: codex_run and antigravity_run target different external CLIs, and bridge_status is the health/status reporter. There is no meaningful overlap or ambiguity between them.
The two worker tools follow a consistent <cli>_run pattern, while bridge_status deviates by using a noun instead of a verb. This is a minor inconsistency in an otherwise predictable naming scheme.
Three tools is well-scoped for a bridge server: one for each external worker and one for status. Every tool earns its place and the count feels appropriate for the server's purpose.
The core workflows of delegating to either CLI and checking bridge health are covered. Minor gaps exist around job lifecycle management (e.g., listing or canceling active jobs), but these are not critical to the stated purpose.
Maintenance
Related MCP Connectors
Orbit is an MCP server that gives your AI agents a 4000+ tools, a shared memory brain and a live dashboard OS. Every agent reads active decisions, logs outputs to a searchable vault, and reports status in real time. 2-minute setup via MCP; works across Claude, ChatGPT, Codex, Cursor, Gemini, and Manus. Finally Agents work, agents that grow your business and bring you customers. https://orbitagents.xyz
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Related MCP Servers
- AlicenseAqualityBmaintenanceA local MCP server that lets Claude delegate scoped work to Codex with structured results and guardrails, supporting planning, code review, build, reverse engineering, and long-running background tasks.1123 PyPIMIT
- AlicenseAqualityAmaintenanceAn MCP server that bridges Claude Code with Antigravity CLI using a Swarm Agent architecture to optimize local development workflows and minimize LLM token costs. Includes a web UI for monitoring agent workflows.29226 PyPI29MIT
- FlicenseNot gradedqualityAmaintenanceA local MCP server that connects AI coding agents like Claude, Codex, and Gemini, enabling task routing, cross-model debates, and token-efficient context sharing without external APIs.18-
- AlicenseNot gradedqualityCmaintenanceAn MCP server that bridges CLI coding agents like Claude Code, Codex, opencode, and Antigravity into any MCP client, enabling synchronous and asynchronous task execution, follow-up input, and a structured code review tool.41 npm2MIT