Agent Bridge MCP

agent-bridge-mcp ist ein lokaler Model Context Protocol (MCP)-Server, der einem MCP-Host eine kontrollierte Möglichkeit bietet, Aufgaben an lokale Coding-Agent-CLIs und die Manus-API zu delegieren. Es ist bewusst kein Agent-Orchestrator mit uneingeschränktem Dateisystemzugriff: Normale Installationen erfordern Konfiguration, Projektwurzeln sind auf eine Whitelist gesetzt, der Standard-Ausführungsmodus ist schreibgeschützt, und die vom Aufrufer gewählte Autorität kann die konfigurierte Obergrenze nicht überschreiten.

Was in v0.3.0-rc.8 implementiert ist

Gemini und Manus sind standardmäßig deaktiviert. Manus muss nach der Konfiguration seiner Berechtigungsnachweise und der Bestätigung der Kontofähigkeiten bewusst aktiviert werden. Die Remote-Prompt-Übertragung ist separat standardmäßig deaktiviert und erfordert eine Agent/root/data-class-Whitelist, allow_remote_egress=true, eine data_classification und eine verbrauchte exakt begrenzte remote_egress-Genehmigung bei jedem Aufruf. Jeder direkte Remote-Aufruf erfordert außerdem eine separate paid_or_unknown_cost-Genehmigung, da eine vom Aufrufer gelieferte Null nicht beweisen kann, dass die Anbieterkosten null sind. Beide Kategorien sind immer frische Einmal-Datensätze; wiederverwendbare Datensätze werden vor jedem Anbieterstart abgelehnt. Ein optionaler policy.cumulativeRemoteCost-Unterbrecher reserviert atomar das genehmigte Maximum in ganzen USD-Cent vor dem Start über alle Sitzungen hinweg. Unbekannte, Null-, Bruchteil-Cent-, über dem Limit liegende, beschädigte/fehlende Hauptbuch- und gleichzeitige Überbuchungsfälle schlagen vor dem Anbieteraufruf fehl. Persistierte Reservierungen werden nach Erfolg, Fehler, Timeout, Abbruch oder Prozessabsturz nie wieder aufgefüllt, da der Bridge nicht beweisen kann, dass eine angenommene Anfrage nicht abgerechnet wurde. Die Reservierung geht absichtlich dem Genehmigungsverbrauch voraus, sodass ein späterer lokaler Fehler konservativ Budget verbrennen kann, ohne den Anbieter aufzurufen. Dies ist eine Buchhaltung genehmigter Kosten, keine Abrechnungsabstimmung mit dem Anbieter; die Haltbarkeit bei abruptem OS-/Stromausfall hängt weiterhin vom Host-Dateisystem ab. list_agents meldet Erreichbarkeit/Authentifizierung/Fähigkeiten und kooperative Bereitschaft; es ist ein Gesundheitscheck, kein Beweis, dass eine bezahlte Aufgabe abgeschlossen werden kann oder dass ein Remote-Agent auf den angeforderten Arbeitsbereich zugreifen kann.

Manus-Aufgabenreferenzen werden nur akzeptiert, wenn sie dem 22-stelligen alphanumerischen Aufgaben-ID-Vertrag des Anbieters entsprechen. Nach task.create erlaubt RC6 eine begrenzte 15-Sekunden-Sichtbarkeitsfrist: Ein task.listMessages-404 wird gegen task.detail geprüft, bevor er klassifiziert wird. Eine detailbestätigte Aufgabe, deren Nachrichten weiterhin nicht verfügbar sind, wird als unknown gemeldet und ist fortsetzbar; nur eine Aufgabe, die in beiden Oberflächen während der Frist fehlt, wird zu not_found und nicht fortsetzbar. Öffentliche Ergebnisse legen nur SHA-256-Anfragekorrelationen offen, niemals rohe Anbieter-Anfrage-IDs oder native Aufgaben-IDs.

Vor der Vorschau von Genehmigungen oder dem Verbrauch von Autorität führt der Bridge einen rein lokalen Manus-Preflight durch: Eine nicht leere konfigurierte Berechtigung muss vorhanden sein, die Standardfähigkeiten des Kontos müssen bestätigt sein, das Modell muss eines der unterstützten Manus-Profile sein, und der finalisierte Prompt muss in eine konservative Obergrenze von 4.500 UTF-8-Bytes passen. Dieser Preflight stellt keine Anbieteranfrage. Die normale Fortsetzung sendet nur dann eine neue Nachricht an eine Anbieteraufgabe, deren persistierter Zustand stopped ist. Eine waiting-Aufgabe muss den spezialisierten Wartungs-Aktionspfad verwenden. Für ein persistiertes timed_out, aborted, error- oder unknown-Ergebnis erfordert reconcile_manus_task Remote-Egress-Zustimmung, Datenklassifizierung und die aktuelle Sitzungsrevision und führt dann GET-only-Anbieterabfragen durch, ohne eine Benutzernachricht zu senden. Ein lokales Reconcile-Timeout zeichnet die Aufgabe als weiterhin ungelöst auf und sendet niemals eine Anbieter-Stopp-Anfrage; sobald das Reconcile stopped erreicht, ist die normale Fortsetzung wieder verfügbar.

Diese dauerhaften Egress-/Kosten-Genehmigungen pro Aufruf schützen Bridge-verwaltete direkte Remote-APIs wie Manus. Codex, Claude und Gemini sind lokale CLI-Prozesse, können aber Prompts und arbeitsbereichsbezogene Inhalte an ihre gehosteten Anbieter senden; ihre Konto-, Anbieter- und CLI-Richtlinien sind eine äußere Vertrauensgrenze. list_agents meldet directRemoteApi und offMachineEgress getrennt, sodass eine lokale ausführbare Datei niemals mit lokaler Verarbeitung verwechselt wird.

Unter Windows werden direkte ausführbare Dateien ohne Shell gestartet. Kanonische statische npm-generierte .cmd-Shims werden nur erkannt, wenn sie einen enthaltenen node_modules-Einstiegspunkt benennen; dieser Einstieg wird mit der eigenen Node-Executable des Bridges gestartet, sodass Prompts, Modelle, Wurzeln und Erweiterungsargumente niemals durch cmd.exe laufen. Dynamische/benutzerdefinierte .cmd-Dateien und alle .bat-Launcher schlagen mit UNSAFE_WINDOWS_BATCH_SHIM geschlossen fehl. Konfigurieren Sie die zugrunde liegende .exe oder verwenden Sie einen kanonischen statischen npm-.cmd-Shim. Dies verhindert, dass Batch-Metazeichen aus Bridge-Root-, Sandbox- und Genehmigungsgrenzen entkommen.

Installieren und konfigurieren

Erfordert Node.js 20+ und die CLIs, die Sie auf PATH aktivieren.

Wählen Sie den Pfad, der zur Aufgabe passt:

• Aus dem Quellcode entwickeln oder verifizieren: Verwenden Sie die folgenden Befehle und die Quellcode-Entwicklungskonfiguration.

• Eine installierte Version betreiben: Beginnen Sie mit Build, Test und Paket, einschließlich der unveränderlichen Windows-Installations-/Canary-Sequenz, und folgen Sie dann Creator Operations. Zeigen Sie keinen Client auf dist aus dem Quellcode oder direkt auf ein versioniertes Release-Verzeichnis.

npm ci
npm run verify
New-Item -ItemType Directory -Force "$env:USERPROFILE\.agent-bridge" | Out-Null
Copy-Item config.example.json "$env:USERPROFILE\.agent-bridge\config.json"

Die obigen Befehle erstellen eine Quellcode-Entwicklungskonfiguration unter %USERPROFILE%\.agent-bridge\config.json. Die Vorlage hat absichtlich ein leeres allowedRoots-Array und startet erst, wenn Sie es durch ein oder mehrere vorhandene absolute Projektverzeichnisse ersetzen. Eine unveränderliche installierte Version verwendet stattdessen die gemeinsame Konfiguration unter %USERPROFILE%\.codex\agent-bridge\config.json, und jede Codex/Claude-Registrierung muss AGENT_BRIDGE_CONFIG auf diese gemeinsame Datei setzen, während der stabile Shim gestartet wird. Eine Konfiguration kann ansonsten mit --config <path> oder AGENT_BRIDGE_CONFIG ausgewählt werden; eine angrenzende config.json neben dem Server wird nur verwendet, wenn sie vorhanden ist. Fehlende, fehlerhafte oder wurzellose Konfiguration wird abgelehnt, anstatt auf ein uneingeschränktes Verzeichnis zurückzufallen. Lassen Sie nicht zu, dass der Quellcode-Entwicklungs-Fallback und die installierte gemeinsame Konfiguration stillschweigend auseinanderlaufen.

Die Laufzeit-Standardwerte sind ein 600-Sekunden-Timeout und eine read-only-Sandbox. config.example.json verwendet bewusst ein 900-Sekunden-Beispiel-Timeout; es ist nicht der Laufzeit-Standardwert. Die Sandbox-Priorität ist: die Anfrage pro Turn, wenn angegeben, ansonsten defaults.sandbox; diese angeforderte/Standard-Autorität wird dann sowohl durch agents.<id>.sandboxCeiling als auch durch policy.sandboxCeiling eingeschränkt, und das restriktivste Ergebnis gewinnt. Eine workspace-write-Obergrenze erlaubt einen separat angeforderten Schreib-Turn, macht aber selbst Schreibvorgänge nicht zum Standard. policy.sandboxCeiling standardmäßig auf workspace-write für Kompatibilität, sodass Legacy-Konfigurationen weiterhin Schreibvorgänge anfordern können, aber kein full-access mehr anfordern können. Vollzugriff erfordert, dass die Konfiguration explizit "sandboxCeiling": "full-access" sagt. agents.<id>.sandboxCeiling kann das Limit für ein Backend senken. Das Beispiel cumulativeRemoteCost.maxReservedCents ist eine zustandsweite Lebenszeit-Reservierungsobergrenze für das aktuelle Hauptbuch; die Erhöhung ist eine explizite Operator-Aktion, und es gibt absichtlich kein Reset-MCP-Tool. Nach der ersten Reservierung bewirkt ein Initialisierungsmarker, dass das Löschen nur des Hauptbuchs geschlossen fehlschlägt. Ein lokaler OS-Benutzer, der sowohl das Hauptbuch als auch den Marker löschen kann, kann diese Buchhaltungsgrenze zurücksetzen. Halten Sie stateDir daher außerhalb von gemeinsamem/Arbeitsbereichsspeicher und schützen Sie seine ACL. Lassen Sie die Richtlinie weg, um diesen Unterbrecher zu deaktivieren. Der Bridge kanonisiert erlaubte Wurzeln und das Arbeitsverzeichnis und kanonisiert dann unmittelbar vor dem Start erneut, sodass ein Junction-/Symlink-Escape abgelehnt wird.

Ein MCPB-Paket kann sich für denselben Validator entscheiden, ohne eine gefälschte angrenzende Konfiguration zu installieren, indem es AGENT_BRIDGE_BUNDLE_MODE=1 setzt und AGENT_BRIDGE_ALLOWED_ROOT bereitstellt. Der Bundle-Modus standardmäßig auf read-only-Autorität, Codex und Claude aktiviert, und Gemini, Manus und Remote-Egress deaktiviert. Das MCPB-Manifest kann auch AGENT_BRIDGE_STATE_DIR, Backend-AGENT_BRIDGE_ENABLE_*-Umschalter, AGENT_BRIDGE_DEFAULT_SANDBOX und AGENT_BRIDGE_SANDBOX_CEILING bereitstellen. Das Aktivieren von Remote-Egress erfordert zusätzlich Manus plus AGENT_BRIDGE_REMOTE_EGRESS=true und eine AGENT_BRIDGE_REMOTE_DATA_CLASS. Explizite --config- oder AGENT_BRIDGE_CONFIG-Auswahl gewinnt immer über den Bundle-Modus.

Manus-Berechtigung

Führen Sie das mitgelieferte Setup-Skript aus PowerShell aus:

.\scripts\setup-manus.ps1

Es schreibt den Schlüssel nach %USERPROFILE%\.agent-bridge\secrets\manus-api-key mit einer Nur-Benutzer-ACL. Aktivieren Sie agents.manus, setzen Sie credentialFile auf diesen Pfad und setzen Sie acknowledgeAccountDefaultCapabilities=true plus ein stabiles nicht geheimes accountCapabilityProfile-Label nur nach Überprüfung der aktivierten Standardfähigkeiten des Manus-Kontos. Agent Bridge sendet leere connectors, force_skills und Aufgabenreferenzen pro Nachricht bei der Erstellung und löscht Connectors bei der Fortsetzung, aber Manus-API v2 bietet keinen Bridge-erzwingbaren Schalter, der beweist, dass Standardfähigkeiten des Kontos deaktiviert sind. Die Bestätigung zeichnet die Akzeptanz dieser anbieterseitigen Fähigkeitsgrenze auf; sie gewährt keinen lokalen Dateisystemzugriff und autorisiert keine Connector-Aktion. Der Anbieter-Endpunkt, die Version der Anforderungsfähigkeitsrichtlinie und das Konto-Profil-Label sind in jede Remote-Genehmigungshülle eingebunden, sodass eine geänderte Konto-/Fähigkeitsüberprüfung neue Genehmigungen erfordert. Legen Sie den Schlüssel nicht in die Versionskontrolle oder ein MCP-Manifest. Der Manus-Endpunkt ist auf HTTPS api.manus.ai (oder seine Subdomains) beschränkt; die Entwicklungs-Override akzeptiert nur Loopback-HTTP(S). Manus empfängt Aufgabentext über seine API und hat keinen lokalen Dateisystemzugriff; stellen Sie stattdessen relevante Dateiinhalte oder ein remote zugängliches Artefakt bereit.

Ein in den Chat eingefügter Schlüssel ist offengelegt. Rotation ist die empfohlene Abhilfe. Wenn der Operator die Rotation ausdrücklich ablehnt, dokumentieren Sie diese Entscheidung als akzeptiertes Restrisiko, behalten Sie den Schlüssel nur in der ACL-geschützten Berechtigungsdatei und lassen Sie die Berechtigungshygiene selbst als fehlgeschlagen oder bestätigt, anstatt sie als bestanden zu bezeichnen.

MCP-Operationen

get_creator_status ist die rein lokale Creator-Übersicht. Es aggregiert Laufzeit-/Konfigurationszustand, konfigurierte Fähigkeiten, reservierte genehmigte Kosten und eine mutationsfreie begrenzte Stichprobe des Sitzungs-, Genehmigungs- und Workboard-Zustands, ohne eine CLI zu starten oder einen Anbieter zu kontaktieren. Seine scanned-, truncated- und unreadable-Felder sind Stichprobenbeweise und keine unbegrenzten Summen; unvollständiger Zustand erzwingt Aufmerksamkeit. Die Backend-Gesundheit ist absichtlich über list_agents getrennt.

Der Server stellt sequenzielle Bridge-Operationen bereit (list_agents, delegate_task, continue_session, handoff, list_sessions, get_session und seitenweise get_turn_output), passive diagnose_install, schreibgeschütztes get_budget_status, dauerhafte Genehmigungsoperationen (request_approval, decide_approval, list_approvals), exakte Remote-Planung über preview_turn_approval und preview_recommendation_approval, reines GET reconcile_manus_task, schmale Manus-Warteaktions-Operationen (get_manus_waiting_action, preview_manus_confirmation, confirm_manus_action), unabhängiges collect_recommendations sowie kooperative Workboard-Erstellung, -Ausführung, -Überprüfung, -Inspektion, -Lebenszyklus, -Abbruch, -Wiederholung und -Elementgenehmigungsoperationen. Sitzungen behalten intern backend-native IDs für kompatible Fortsetzungen bei. Wenn ein anderer Agent übernimmt oder eine native Fortsetzung nicht verfügbar/inkompatibel ist, stellt die Bridge ein begrenztes, maskiertes Transkript voran, das explizit als nicht vertrauenswürdiger Kontext markiert ist. Eine Remote-Vorschau gibt zwei verschiedene Hashes zurück: prompt_sha256 identifiziert den finalisierten ausgehenden Prompt zum Vergleich, während payload_sha256 den vollständigen Genehmigungs-Envelope identifiziert, einschließlich Modell, Sandbox, Timeout, Kontinuitäts-/Fortsetzungsstatus, Sitzungsrevision, Erweiterungsrichtlinie, Provider-Endpunkt, Version der Anforderungs-Fähigkeitsrichtlinie und nicht-geheimes Konto-Fähigkeitsprofil. Genehmigungsdatensätze müssen den Envelope-Hash verwenden. Geben Sie die session_revision der Vorschau bei Fortsetzung oder Übergabe zurück, sodass gleichzeitige Transkriptänderungen eine neue Vorschau erfordern. Inline-Agent-Ausgabe wird abgeschnitten; verwenden Sie den zurückgegebenen output_ref oder get_turn_output, um die vollständige persistierte Ausgabe in begrenzten Seiten abzurufen.

Manus-Warteaktionen

Manus-Aufgaben können in einem waiting-Zustand pausieren. Agent Bridge speichert nur die native Aufgaben-ID, Ereignis-ID und einen bekannten Ereignistyp; Provider-Beschreibungen und dynamische Schemata werden bewusst verworfen, da sie Geheimnisse, personenbezogene Daten oder neue Berechtigungen enthalten können. Die öffentlichen Tools geben niemals die native Aufgaben-ID zurück. Obwohl Manus viele Bestätigungstypen dokumentiert und weitere hinzufügen kann, erlaubt diese Version nur vier feste Entscheidungen:

Jede Entscheidung erfordert außerdem eine frische einmalige remote_egress-Genehmigung, eine zulässige Datenklasse/-wurzel, den exakten Vorschau-Digest und die unveränderte Sitzungsrevision. Die Bestätigungsvorschau legt einen Ausführungs-Envelope offen, der den Provider-Endpunkt, die Connector-/Standard-Skill-Fähigkeitsrichtlinienversion und das nicht-geheime Konto-Profil bindet. Der Adapter liest die neueste Live-Provider-Aktion erneut, bevor er entweder die Genehmigung verbraucht oder Budget reserviert. Nur nach erfolgreicher erneuter Validierung verpflichtet er die Berechtigung, speichert den versuchten Bestätigungsdatensatz unmittelbar vor dem nicht-idempotenten task.confirmAction-POST und verlangt dann, dass die Antwort ok=true, confirmed=true und dieselbe Aufgaben-ID zurückgibt. Die akzeptierte Bestätigung wird gespeichert, bevor die Bridge die Abfrage wieder aufnimmt. Unbekannte Aktionen, Benutzerfragen, Browserauswahl, tatsächliches E-Mail-Senden, Premium-Video, Kreditakzeptanz, Geheimnisse, Deployments, Terminalbefehle, Kalender-/Marketingaktionen, Connector-Autorisierung und dauerhafte global_allow/always_allow-Gewährungen schlagen fehl (fail closed). Dieser bewusst engere Vertrag sitzt auf der Manus-Aufgabenlebenszyklus- und task.confirmAction-API.

Beginnen Sie mit docs/CREATOR_OPERATIONS.md. Die zugehörige Bedrohungsmatrix, Live-Abnahme-Checkliste, Evidenzkonventionen, Datenschutzgrenze und Beispiele definieren den unterstützten Creator-Workflow und die vor der Promotion erforderliche Evidenz.

Kooperative Workboards

Ein Workboard hat explizite Lebenszyklus-Zustände active, paused, completed, canceled und archived. Elemente können Art, Abnahmekriterien, Daten-/Dateisystem-/Netzwerk-/Fähigkeitsanforderungen, inerte typisierte Artefakt-/Evidenzreferenzen und ein Workflow-Genehmigungsgate deklarieren. Lebenszyklusänderungen verweigern Live-Leases; Wiederholungen löschen Ergebnisse, ohne Versuche oder Nutzung aufzufüllen.

Ein Workboard enthält abhängigkeitsbewusste Arbeitselemente unter stateDir/workboards. Persistierte Boards verwenden eine explizite Schema-Version und werden beim Laden/Speichern rekursiv validiert. Die ursprüngliche unversionierte v0.3-dev-Form wird beim Lesen im Speicher migriert und beim nächsten gesperrten Speichern persistiert, wodurch eine ungesperrte Migrationsrace vermieden wird. Unbekannte zukünftige Schemata, beschädigte Datensätze und inkonsistente Status-/Einreichungs-/Überprüfungskombinationen schlagen fehl (fail closed). Jedes Element hat ein Versuchs-/Zeitbudget, einen Eigentums-Lease, eine isolierte Bridge-Sitzung, eine Einreichung und eine unabhängige Überprüfung. Ausführungs- und Überprüfungs-Wall-Time-/Turn-Nutzung werden getrennt verbucht. Das Überprüfungsversuchslimit wird intern aus maxAttempts abgeleitet; fehlgeschlagene Reviewer-Aufrufe verbrauchen es, behalten die Einreichung für einen erneuten Versuch und blockieren das Element, wenn es erschöpft ist. token_budget_hint ist nur beratend, da die Backend-Token-Abrechnung nicht vergleichbar oder konsistent verfügbar ist. Separate bereite Elemente können gleichzeitig bis zu maxParallel laufen, aber jede Workboard-Ausführung und -Überprüfung wird unabhängig von der Bridge-Standardeinstellung auf read-only erzwungen. Strikte kooperative Turns unterdrücken konfigurierte extraArgs und extraEnv, sodass diese Einstellungen die Read-only-Flags nicht überschreiben können. Ein Reviewer kann nicht der Agent sein, der das Element eingereicht hat. Nur akzeptierte Einreichungen werden in das begrenzte Integrator-Briefing aufgenommen.

Aktuelle Workboards übergeben ein lokales cwd und Text, kein remote zugängliches, hash-verifiziertes Artefaktbündel. Manus kann daher kein Workboard-Element ausführen oder unabhängig überprüfen und wird als nicht kooperationsbereit für lokale Code-Evidenz gemeldet. Verwenden Sie es nur über eine ausdrücklich genehmigte direkte Remote-Delegation, bis ein Artefaktvorbereitungs-Workflow implementiert ist. Der brief-Umfang der Empfehlung ist bewusst auf Backends beschränkt, die keine lokale Dateisystemfähigkeit melden; Codex und Claude müssen den workspace-Umfang verwenden, während Manus nur den gelieferten Brief überprüfen darf. Diese Grenze beweist nur, dass das Backend den lokalen Arbeitsbereich nicht über Agent Bridge einsehen kann. Sie erzwingt nicht provider-seitiges Read-only oder Verhalten ohne Nebenwirkungen; Manus-Kontostandard-Skills bleiben eine anerkannte externe Fähigkeit. Die Sammlung zeichnet briefSha256 auf, sodass das Inline-Artefakt identifiziert werden kann, ohne Arbeitsbereichszugriff zu implizieren.

Diese Entwicklungsversion erlaubt bewusst keine kooperative Schreibarbeit. Sitzungsbezogene Sperren können nicht verhindern, dass zwei separate Agent-Sitzungen dieselben Dateien bearbeiten. Sichere parallele Schreibvorgänge erfordern daher ein späteres Workspace-Eigentumsdesign.

Passive Diagnose

diagnose_install und --doctor --json melden Laufzeit-/Konfigurationsidentität, den Konfigurationsinhalt-Hash, wenn lesbar, Root-Scope-Warnungen, Zustandsgröße/Sitzungsanzahl, bereinigten Backend-Status und Hinweise auf ausführbare Pfadabweichungen. Sie legen absichtlich ausgewählte lokale Pfade offen: den Laufzeitpfad, Zustandspfad, konfigurierte/aufgelöste ausführbare Pfade und Wurzeln, die durch Scope-Warnungen benannt werden. Sie lassen rohe Konfigurationsbytes, Agent-Umgebungsvariablen, Anmeldedatenwerte, rohe Provider-/CLI-Details, Prompts und Transkripte aus. Betten Sie keine Geheimnisse in Dateisystempfade ein. Ein lokales Authentifizierungsergebnis von unknown wird nicht als nutzbar betrachtet. Diese Befehle testen aktivierte Backends; verwenden Sie scripts/inspect-install.ps1 für passive Registrierungs-/Prozess-/ACL-Evidenz, ohne einen Agenten zu starten oder zu delegieren. Sein Ergebnis fallbackConfig.divergentRegistrationRisk=true bedeutet, dass eine Bridge-Registrierung eine andere angrenzende/Statuskonfiguration lesen kann als die installierte gemeinsame Konfiguration und ist ein Cutover-Blocker. RC6 erkennt auch gültige einfach-quotierte TOML-Strings in Codex-Registrierungsevidenz.

Experimentelle Daemon-/Proxy-Laufzeit

Der Quellcode enthält eine experimentelle lokale IPC-Daemon-/Proxy-Laufzeit, die auf dem begrenzten Framed-RPC-Codec und dem protokoll-/konfigurationsgebundenen gegenseitigen HMAC-Handshake basiert. Sie verwendet nur Windows Named Pipes oder Unix Domain Sockets – niemals TCP – und implementiert expliziten Lebenszyklus, exklusive Endpunktbindung, strikten Handshake-Zustand, Anforderungskorrelation, Verbindungs-/In-Flight-Limits, Handler-Abbruch bei Trennung und sauberes Herunterfahren. Das Importieren oder Konstruieren startet nichts; Tests verwenden nur Wegwerf-Endpunkte. Es ist nicht in den MCP-Einstiegspunkt oder das Release-Paket eingebunden, sodass direkter stdio der einzige unterstützte Laufzeitpfad bleibt.

Unter Unix wendet die Laufzeit Modus 0600 auf den Socket an. Die net-API von Node kann keine benutzerbezogene Windows-Named-Pipe-ACL konfigurieren oder verifizieren oder die Peer-Identität offenlegen. Daher meldet die Windows-Sicherheitsevidenz diese Lücke wahrheitsgemäß und bietet einen Fail-closed-Autorisierungshook. Stellen Sie den experimentellen Daemon nicht bereit, bis eine Windows-ACL-Bereitstellungs-/Verifizierungsschicht und ein MCP-Routing-Adapter implementiert und überprüft sind.

Verwenden Sie die Prozessdiagnose, bevor Sie sie zu einem MCP-Host hinzufügen:

node .\dist\agent-bridge.mjs --config "$env:USERPROFILE\.agent-bridge\config.json" --doctor

--doctor beendet sich mit einem Nicht-Null-Exitcode, wenn ein aktiviertes Backend nicht nutzbar ist. Es meldet Konfigurationsquelle, Wurzeln, Sandbox und Backend-Gesundheit; es führt keine funktionale delegierte Aufgabe aus.

Daten, Sperren und Grenzen

Bridge-Zustand liegt unter stateDir (Standard %USERPROFILE%\.agent-bridge): Klartext-Sitzungen, Workboards, Genehmigungen, kumulative Budgetreservierungen und deren Sperrverzeichnisse. Sitzungs- und Budgetschreibvorgänge sind atomare Ersetzungsschreibvorgänge; Budget-Temp-Bytes werden vor dem Umbenennen geleert und das übergeordnete Verzeichnis wird synchronisiert, wo die Plattform es erlaubt. Eine laufende Sitzung hält eine Sperre; ein anderer Turn wartet bis zu sessionLockWaitMs und schlägt dann mit SESSION_BUSY fehl. Das kumulative direkte Remote-Ledger verwendet eine separate token-gebundene Sperre, sodass verschiedene Sitzungen es nicht überzeichnen können. Im Gegensatz zu normalen Sitzungs-/Workboard-Sperren wird die Ausgabensperre nie automatisch zurückgefordert: Ein pausierter alter Eigentümer könnte sonst eine neuere Reservierung überschreiben. Wenn sein Prozess abstürzt, schlagen direkte Remote-Starts fehl (fail closed), bis jeder Bridge-Host gestoppt ist und ein Operator nur stateDir\budget-locks\cumulative-remote-cost.lock entfernt.

Sitzungstranskripte sind im Ruhezustand Klartext-JSON. Sie können Prompts, Ausgaben, Fehlerenden, Pfade und sensiblen Aufgabenkontext enthalten. Schützen Sie stateDir, geben Sie keine Geheimnisse in Prompts ein und behandeln Sie get_session als Offenlegung des gespeicherten Transkripts. get_session entfernt absichtlich native Backend-IDs und Metadaten und begrenzt jedes zurückgegebene Feld, ist aber keine Verschlüsselung oder Schwärzung. Die Bridge übergibt eine begrenzte Klartext-Kontextzusammenfassung zwischen Agenten; Kürzung kann früheren Kontext weglassen, daher sollten kritische Entscheidungen im aktuellen Prompt wiederholt werden.

Build, Test und Paketierung

npm run verify
node .\scripts\package.mjs

npm run package erstellt zuerst; npm pack erstellt ebenfalls über seinen prepack-Hook. Der Release-Befehl erfordert einen ausgecheckten Git-Commit, erstellt ein frisches .release-staging-Verzeichnis, erzeugt agent-bridge-v<package-version>.mcpb und verifiziert, dass das gepackte server/agent-bridge.mjs, seine Source Map und die Windows-Betriebsskripte byteweise mit den committeten Kandidaten-Eingaben übereinstimmen. Das Bundle enthält manifest.json, die Laufzeit, ihre Source Map, operations/ und release-metadata.json; jede Laufzeit- und Betriebs-Payload ist in den Release-Metadaten per SHA-256 und Byteanzahl festgelegt. Der Betriebssatz ist bewusst schmal: Readiness, der One-Lock-Cutover, Immutable-Release-Rollback, passive Inspektion, Client-Registrierung und ihre gemeinsamen Sicherheitsmodule. Er verweigert einen vorhandenen Ausgabepfad und ändert niemals einen installierten MCP-Server. Installieren Sie kein Entwicklungspaket über aktive Hosts; verwenden Sie ein neues unveränderliches Verzeichnis und verschieben Sie Registrierungsänderungen, bis laufende Aufgaben abgeschlossen sind.

Das MCPB verwendet das Manifest-Schema 0.3 und die vom Host bereitgestellte user_config; es bettet keine veränderbare Platzhalter-Konfiguration ein. Der Paketierungsbefehl meldet sowohl Bundle- als auch Laufzeit-SHA-256-Werte. Validieren Sie manifest.template.json mit der offiziellen MCPB-CLI vor einem Release. Unter Windows installieren und inspizieren Sie ein Artefakt, ohne den aktiven Zeiger zu berühren:

.\scripts\install-release.ps1 -BundlePath .\agent-bridge-v0.3.0-rc.8.mcpb -ExpectedBundleSha256 <reported-bundle-sha256>
$candidate = "$env:USERPROFILE\.codex\agent-bridge\releases\<release-id>"
& "$candidate\operations\inspect-install.ps1"
node .\scripts\canary-release.mjs --release-path "$env:USERPROFILE\.codex\agent-bridge\releases\<release-id>" --install-root "$env:USERPROFILE\.codex\agent-bridge" --expected-version 0.3.0-rc.8 --expected-runtime-sha256 <reported-runtime-sha256> --evidence-dir "<durable-private-root>\installed-canary"
node .\scripts\canary-windows-shim.mjs --release-path "$env:USERPROFILE\.codex\agent-bridge\releases\<release-id>" --install-root "$env:USERPROFILE\.codex\agent-bridge" --expected-version 0.3.0-rc.8 --expected-runtime-sha256 <reported-runtime-sha256> --evidence-dir "<durable-private-root>\windows-shim-canary"

Der provider-deaktivierte Canary für installierte Releases startet die absolute unveränderliche Laufzeit mit wegwerfbarem config/state/root, verifiziert alle erforderlichen MCP-Tools und die diagnostische Identität und beweist, dass der stabile Shim, die gemeinsame Konfiguration und der Promotionsmarker unverändert geblieben sind. Der Windows-Shim-Canary führt dieselbe installierte Laufzeit mit einem lokalen Mock-CLI hinter einem kanonischen npm .cmd in einem Pfad mit Leerzeichen aus; er verifiziert die Laufzeitidentität, exakte feindliche argv-Erhaltung, schreibgeschützte Delegation, keinen Shell-Injection-Sentinel und unveränderte stabile Dateien, ohne einen Provider aufzurufen. Erstellen Sie neue dauerhafte private Beweisverzeichnisse außerhalb des stabilen Installationsstamms. Provider-gestützte Release-Tests akzeptieren einen absoluten AGENT_BRIDGE_SERVER_PATH plus erforderliche AGENT_BRIDGE_INSTALL_ROOT, AGENT_BRIDGE_EXPECTED_VERSION und AGENT_BRIDGE_EXPECTED_RUNTIME_SHA256; sie verifizieren, dass sich die Laufzeit genau unter releases\<release-id>\server dieser Installation befindet. Setzen Sie AGENT_BRIDGE_LIVE_REQUIRED=1, damit Quell-dist-, Authentifizierungs- oder Kontingent-Überspringungen nicht als Release-Bestand fehlinterpretiert werden können, und behalten Sie jedes strukturierte Ergebnis als bereinigtes JSON.

Der Manus-Harness ist eine zweistufige, dauerhafte Einmal-Transaktion. Vorschau mit node test/live-manus.mjs --evidence-dir <new-absolute-private-directory>; die Vorschau führt nur lokale Identitäts-/Anmeldedatenprüfungen durch, erstellt eine kryptografische Nonce und ein ausstehendes Ticket und tätigt keinen Manus-API- oder Health-Aufruf. Überprüfen Sie die Vorschau und führen Sie dann den exakten nonce-gebundenen Befehl aus, den sie ausgibt. Die Ausführung verbraucht das Ticket atomar vor dem Bridge-Start, der Genehmigungseinholung, Health-Probes oder bezahlter Arbeit; eine Wiederholung schlägt fehl. Sie löscht umgebungsbedingte MANUS_API_KEY und MANUS_API_BASE_URL, erfordert exakte Ausgabe und gestoppten Status, verifiziert das Budget-Delta und beide verbrauchten Genehmigungen und behält private config/state/work/result-Beweise bei, anstatt sie zu löschen.

Ignorierte RC5/RC6/RC7-Bundles und ihre .release-staging-Verzeichnisse sind nur historische Artefakte. Sie sind keine RC8-Eingaben und dürfen niemals als aktueller Kandidat gefördert werden.

Nach der Promotion und der Akzeptanz durch neu gestartete Clients erstellen Sie einen strengen Deskriptor aus dem Beispiel innerhalb eines operator-kontrollierten Beweisstamms und führen Sie npm run evidence:release -- --descriptor <absolute-descriptor.json> --output-dir <evidence-root>\<packet-id> --require-accepted aus. Der Basisname des Ausgabeverzeichnisses muss der Paket-ID entsprechen. Der Exporteur verifiziert die installierten Metadaten, den Promotionsmarker, die gemeinsame Konfiguration, die Bundle-Inhalte, die Kandidaten-Hashes und das benannte Akzeptanzprofil; er akzeptiert Eingabeartefakte nur aus diesem kanonischen Beweisstamm, lehnt vertrauliche/eingeschränkte Daten und Überschreibungen ab, redigiert narrative/Provider-ID-JSON-Felder, selbst wenn privater Zustand umbenannt wurde, und scannt JSON-Schlüssel und -Werte auf Manus-native Identifikatoren, bevor er synchronisierte evidence-report.json, evidence-report.md und manifest.json ausgibt. Führen Sie npm run evidence:verify -- --packet-dir <absolute-packet-directory> aus, um fehlende, zusätzliche oder geänderte Dateien zu erkennen. Das Manifest ist eine Integritäts-Querprüfung, keine Signatur gegen einen bösartigen lokalen Editor. Schützen Sie die Windows-ACL des Beweisstamms separat. Die Promotion ist vorläufig, bis der endgültige akzeptierte Export erfolgreich ist. Ein blockiertes Pre-Promotion-Paket kann ohne --require-accepted exportiert werden; es ist Beweis, keine Akzeptanz.

Vorschau der Registrierungsnormalisierung für Codex, Claude Code und erkannte Claude-Desktop-Profile mit <candidate-release>\operations\configure-clients.ps1. Es ist standardmäßig ein Trockenlauf, verweigert aktive Zielprozesse oder mehrdeutige Registrierungen und unterstützt ein exaktes Byte-Wiederherstellungsmanifest für geänderte Dateien. Verwenden Sie seinen eigenständigen -Apply-Modus nicht für einen normalen Release-Cutover. Führen Sie Release-Operationen aus dem installierten unveränderlichen Verzeichnis des Kandidaten aus, nicht aus einem veränderbaren Quell-Checkout.

Der Release-Cutover ist eine bewusste Wartungsfenster-Operation, keine unbeaufsichtigte Watcher-Aktion. Beenden Sie Codex, Claude Code, Claude Desktop und andere MCP-Hosts vollständig und führen Sie dann <candidate-release>\operations\check-cutover-readiness.ps1 aus. Es erfordert wiederholte leere Stichproben über Agent-Bridge-Knoten und bekannte Codex/Claude-Hostfamilien und -Nachkommen. Verwenden Sie <candidate-release>\operations\cutover-release.ps1 -ReleaseId <version+sha7> für die tatsächliche One-Lock-Registrierungs- und Release-Transaktion. Der Watcher darf Bereitschaft melden, aber niemals einen Mutationsbefehl aufrufen. Dies ist operative Ruhe und keine OS-erzwungene Startbarriere; ein während des Fensters geöffneter Host führt dazu, dass die Transaktion abbricht und überall dort wiederherstellt, wo dies erkennbar ist.

Vor dem Cutover kann scripts\rehearse-rollback.ps1 exakte Hash-Kandidaten- und frühere Bundles in eine brandneue externe Fixture installieren, Kandidat → früher → Kandidat wechseln, den stabilen Shim der Fixture und provider-deaktivierte MCP-Canaries ausüben und ein gehashtes Beweis-Manifest behalten. Es akzeptiert keinen Live-Installations- oder Client-Registrierungspfad. Das vertrauenswürdige Wechsel-Primitiv erfordert weiterhin, dass jeder MCP-Host geschlossen ist, und dieser Wegwerfbeweis ersetzt nicht die Live-Rollback-Übung nach dem Cutover.

<trusted-release>\operations\switch-release.ps1 ist das untergeordnete Release-/Rollback-Primitiv. Es verifiziert die Ziel-installierte Laufzeit, verwendet einen verweigernden Wartungs-Shim, schreibt den Release-Marker, bevor es den Live-Shim aktiviert, erstellt ein exaktes Rollback-Backup und schlägt bei aktiven Prozessen geschlossen fehl. Verwenden Sie die neuesten verifizierten Betriebsskript-Bytes, auch wenn sein -ReleaseId-Ziel eine ältere installierte Laufzeit ist. protect-state.ps1 ersetzt geerbte ACLs des Zustandsverzeichnisses durch expliziten Zugriff für den aktuellen Benutzer, SYSTEM und Administratoren; überprüfen Sie sein Ziel, bevor Sie -Force verwenden.

Siehe HANDOFF.md für das Release- und Rollback-Verfahren und SECURITY.md für das Sicherheitsmodell.