Skip to main content
Glama

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.md und docs/roles.md. In Arbeit: eine Provider-Adapter-Schicht (src/providers/), ein Routing-Profil (src/profile/) und ein agentbridge 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

docs/install-codex.md

über MCP-Prompts, plus hosts/codex/AGENTS.md

Claude Code

MCP-Server registrieren, dann optional hosts/claude-code/skills/agentbridge in ~/.claude/skills/ kopieren

über MCP-Prompts

Befehl

Funktion

agentbridge <goal>

Arbeit abschätzen, planen, delegieren, verifizieren, berichten

agentbridge_setup

CLIs erkennen, nachweisen, dass jede funktioniert, Routing-Profil schreiben

agentbridge_status

was installiert ist und wie Rollen abgebildet werden; keine Inferenz

agentbridge_doctor

mit echten Smoke-Jobs diagnostizieren und sagen, was zu beheben ist

agentbridge_profile

Routing anzeigen oder neu ableiten, optional für eine Rolle

agentbridge_recon

eine abgegrenzte Repository-Untersuchung

agentbridge_review

unabhängiges Review durch eine andere Modellfamilie

agentbridge_resume

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 continues

Related 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

  1. Claude ruft codex_run oder antigravity_run mit einer strukturierten Anfrage auf (goal, mode, model, effort, paths, contract, acceptance criteria…).

  2. AgentBridge setzt aus genau diesen Feldern einen Worker-Prompt zusammen. Es führt kein eigenes Modell aus — das ist String-Zusammenbau, keine Inferenz.

  3. Es reserviert Schreibbereiche, erstellt einen Snapshot des git-Arbeitsbaums und startet die CLI mit einem Argument-Array (shell: false).

  4. 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 PATH, bereits angemeldet (codex login) — verifiziert gegen codex-cli 0.147.0

Antigravity CLI

agy auf PATH, bereits angemeldet — verifiziert gegen agy 1.1.12

git

optional, aber dringend empfohlen; ohne git können files_changed / scope_violations nicht berechnet werden

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 install
npm run build
npm test

Die 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.js

Von einem Terminal aus verifizieren:

claude mcp list
claude mcp get agentbridge

Dann 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:

  1. AGENTBRIDGE_PROJECT_DIR, dann das bisherige CLAUDE_PROJECT_DIR (das Claude Code exportiert).

  2. Das erste file://-Wurzelverzeichnis, das der MCP-Client bekannt gibt.

  3. Das Arbeitsverzeichnis des Serverprozesses.

bridge_status berichtet, welches verwendet wurde.


Tools

codex_run

Feld

Typ

Hinweise

goal

string

erforderlich

mode

analyze | implement | review

erforderlich

model

gpt-5.6-sol | gpt-5.6-terra | gpt-5.6-luna

erforderlich

effort

light | medium | high | extra high | max

erforderlich

relevant_files

string[]

Dateien, die zuerst angesehen werden sollen

allowed_paths

string[]

erforderlich im Modus implement

no_touch

string[]

Pfade, die der Worker nicht verändern darf

context

string

Hintergrundwissen, das das Repo nicht enthält

contract

string

Schnittstellen/Typen, die exakt eingehalten werden müssen

acceptance_criteria

string[]

tests

string[]

Kontext für den Worker — AgentBridge führt diese selbst nie aus

timeout_seconds

number

Standard 900, begrenzt auf 30–3600

Modelle. Drei Slugs sind adressierbar, und jeder wird unverändert an die CLI übergeben:

model

Was es ist

gpt-5.6-sol

stärkstes allgemeines Engineering-Modell

gpt-5.6-terra

Spezialist für tiefes Brownfield / bestehende Codebasen

gpt-5.6-luna

wirtschaftliches Arbeitstier für hohe Volumina

Effort-Mapping (Orchestrator-Bezeichnung → Codex model_reasoning_effort):

light

medium

high

extra high

max

low

medium

high

xhigh

max

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, mit details.supported_efforts

  • Modell nicht gelistet → requested_model_unavailable, mit details.available_models

  • kein lesbarer Katalog → der Auftrag läuft trotzdem, mit einer Warnung, dass die Verfügbarkeit unverified war

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 never

wobei 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

model

Gemini Flash 3.7

erforderlich

effort

light / medium / high

optional, standardmäßig medium

Logische Namen werden zur Laufzeit gegen die aktuelle agy models-Liste aufgelöst:

Bezeichnung

Effort

Wird aufgelöst zu (auf diesem Rechner)

Gemini Flash 3.7

light

gemini-3.7-flash-low

Gemini Flash 3.7

medium

gemini-3.7-flash-medium

Gemini Flash 3.7

high

gemini-3.7-flash-high

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-basierte files_changed / scope_violations hier überhaupt funktionieren. Wenn nicht, ist ein leeres scope_violations Stille, kein sauberes Gesundheitszeugnis, und die Warnungen sagen das

  • codex.installed / version / path / auth

  • codex.model_status – pro Modell: available | unavailable | unverified, die AgentBridge-Effort-Labels, die es akzeptiert, und die rohen Reasoning-Ebenen der CLI

  • codex.model_source – woher die Verfügbarkeit stammt und wie frisch sie ist

  • antigravity.installed / version / path / auth, erkannte Modelle, wie jedes logische Label + Tier aufgelöst wurde, und model_status in derselben Drei-Zustands-Form

  • antigravity.unsupported_efforts – die Orchestrator-Labels, die Flash nicht übernehmen kann

  • aktive 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

executable_not_found

codex / agy nicht im PATH

authentication_required

die CLI meldete ein Anmeldeproblem – melde dich selbst erneut an

requested_model_unavailable

das angeforderte Modell wird nicht angeboten; es wurde kein Ersatz vorgenommen

invalid_effort

Effort-Label außerhalb der fünf unterstützten Werte

invalid_arguments

z. B. implement-Modus ohne allowed_paths

scope_conflict

ein anderer aktiver Worker besitzt bereits überlappende Schreibpfade

scope_violation

ein angegebener Pfad hat das Projektverzeichnis verlassen, oder der Worker hat außerhalb seines Bereichs geschrieben

timeout

der Worker hat die Zeit überschritten; sein Prozessbaum wurde beendet

process_failed

Nicht-Null-Exit oder eine Nicht-SUCCESS-CLI-Hülle

output_parse_failed

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

  • implement erfordert allowed_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 mit scope_conflict abgelehnt. Disjunkte Bereiche laufen parallel – unzusammenhängende Arbeit wird nie serialisiert.

  • analyze und review reservieren 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: false erzeugt – 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 als node <script> ausgeführt, sodass shell: true nie 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.

  • tests ist 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 /F unter 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 also taskkill selbst 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 deine allowed_paths entsprechend 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.json und führt die Skripte typecheck und test aus, falls sie existieren. Es führt build, dev oder start nie 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

AGENTBRIDGE_PROJECT_DIR

Projektverzeichnis; hostneutral, bevorzugt

CLAUDE_PROJECT_DIR

Legacy-Name, weiterhin berücksichtigt; von Claude Code gesetzt

AGENTBRIDGE_DEBUG=1

bereinigte Prompts und Ausgaben protokollieren

AGENTBRIDGE_LOG_DIR

Protokollspeicherort (Standard ~/.agentbridge/logs)

AGENTBRIDGE_CODEX_BIN

expliziter Pfad zur Codex-CLI

AGENTBRIDGE_AGY_BIN

expliziter Pfad zur agy-CLI

AGENTBRIDGE_CODEX_SANDBOX

Codex-Sandbox-Richtlinie festlegen: read-only, workspace-write, danger-full-access oder auto (Standard)

AGENTBRIDGE_CODEX_WINDOWS_SANDBOX

Windows-Sandbox-Backend (Standard unelevated)

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.mjs

Dieser 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 check

Available Tools

3 tools
antigravity_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.

NameRequiredDescriptionDefault
goalYesWhat the worker must accomplish. Be specific and self-contained.
modeYesanalyze/review are read-only investigations; implement makes changes and runs checks.
modelYesAntigravity model to run.
testsNoTests or checks the worker should run. Context for the worker only — use `verify_commands` for anything AgentBridge should execute.
effortNoFlash 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.
contextNoBackground the worker needs but cannot infer from the repository.
contractNoInterfaces, types, or API shapes the worker must conform to exactly.
no_touchNoProject-relative paths the worker must not modify.
allowed_pathsNoProject-relative paths the worker may write. Required in implement mode; overlapping scopes across concurrent implement jobs are rejected.
relevant_filesNoProject-relative files the worker should look at first.
timeout_secondsNoWall-clock limit for the worker process. Default 900s, clamped to 30-3600s.
acceptance_criteriaNoConditions that must hold for the job to be considered done.

TDQS

A3.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

NameRequiredDescriptionDefault

No parameters

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

NameRequiredDescriptionDefault
goalYesWhat the worker must accomplish. Be specific and self-contained.
modeYesanalyze/review are read-only investigations; implement makes changes and runs checks.
modelYesCodex 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.
testsNoTests or checks the worker should run. Context for the worker only — use `verify_commands` for anything AgentBridge should execute.
effortYesReasoning effort: light->low, medium->medium, high->high, 'extra high'->xhigh, max->max.
contextNoBackground the worker needs but cannot infer from the repository.
contractNoInterfaces, types, or API shapes the worker must conform to exactly.
no_touchNoProject-relative paths the worker must not modify.
allowed_pathsNoProject-relative paths the worker may write. Required in implement mode; overlapping scopes across concurrent implement jobs are rejected.
relevant_filesNoProject-relative files the worker should look at first.
timeout_secondsNoWall-clock limit for the worker process. Default 900s, clamped to 30-3600s.
verify_commandsNoCommands 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_verificationNoSet 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_criteriaNoConditions that must hold for the job to be considered done.
verify_timeout_secondsNoWall-clock limit for each verification command. Default 300s.

TDQS

A4/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

  1. 3 tool updatesv1.0.0
    • First observedantigravity_run
    • First observedbridge_status
    • First observedcodex_run

TDQS

A4.1/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityStale
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    A 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.
    11
    23 PyPI
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    An 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.
    29
    226 PyPI
    29
    MIT
  • F
    license
    Not graded
    quality
    A
    maintenance
    A 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
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    An 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 npm
    2
    MIT