Cloud-Connectors

connector-cloud ist ein Architektur-Plugin von OHarness, kein MCP. Die Cloud verwaltet den Composio-Projektschlüssel und die freigegebene App- und Tool-Konfiguration. Clients verwenden ihre OHarness-Anmeldung; Gmail-OAuth-Anmeldedaten bleiben bei Composio, beschränkt auf die serverseitig verifizierte OHarness-Nutzer-ID. Neue Supabase-Tabellen sind nicht nötig.

Konfiguration

• Laufzeit-Secret der Cloud-Website: COMPOSIO_API_KEY. Nie NEXT_PUBLIC_ und nie in config.json oder plugins.json des Nutzers, im Browser-Bundle oder im Modellkontext.
• Aktivierte Apps werden aus den Auth Configs im Composio-Projekt abgeleitet, nicht aus einer Datei. Eine Auth Config mit einer Tool-Beschränkung ist eine aktivierte App, und diese Beschränkung ist ihre Allowlist; eine neue Integration ist also eine Aktion im Dashboard, kein Deployment. Die Ableitung lehnt ab, statt anzunehmen: Eine Konfiguration, die keine Tools beschränkt, wird übersprungen (Composio liest eine fehlende Beschränkung als jedes Tool des Toolkits), zwei aktivierte Konfigurationen für ein Toolkit aktivieren keine von beiden, und deaktivierte Konfigurationen, unbrauchbare IDs oder fehlerhafte Tool-Namen lassen die betreffende App wegfallen. Die Obergrenzen von 20 Apps und 40 Tools bleiben unverändert. Die Menge wird einmal pro Prozess aufgelöst; starten Sie die Cloud nach einer Änderung im Dashboard also neu.
• website/connectors.json der Cloud ist jetzt optional und kann nur einschränken: {"disabled": ["slug"]} hält eine App zurück, ohne Composio anzufassen. Eine Datei, die noch toolkits enthält, behält das ältere explizite Verhalten. Das Deployment kann OHARNESS_CONNECTORS_FILE stattdessen auf einen absoluten, eingehängten Pfad zeigen lassen. Die Datei ist bewusst per gitignore ausgeschlossen; binden Sie sie also nur ein, wenn Sie sie verwenden.
• Die bestehende Supabase-Umgebung der Website validiert OHarness-Anmeldetokens.
• Client-cloud.json: optional { "siteUrl": "http://localhost:4000" } für die lokale Entwicklung; Standard ist die öffentliche Cloud-Adresse. Eine Änderung des Cloud-Origins kann eine erneute Anmeldung erfordern. OHARNESS_SITE_URL ist ein alternativer Override.
• Client-plugins.json: Das Standard-Plugin braucht keinen Eintrag. Zum Deaktivieren: { "runtimePlugins": [{ "id": "connector-cloud", "enabled": false }] }.

Legen Sie die Gmail-OAuth-Auth-Config im Composio-Dashboard für dasselbe Projekt an wie den API-Schlüssel. Prüfen Sie ihre Scopes und verwenden Sie für Leseaufgaben nur lesenden Gmail-Zugriff; die Ausführungs-Allowlist ersetzt keine OAuth-Scopes nach dem Prinzip der geringsten Rechte. Die Beispielkonfiguration enthält Platzhalter, keine funktionierenden Anmeldedaten.

Wenn Sie OHarness_Cloud/dev.sh verwenden, setzen Sie die Cloud-Variablen im Prozess der Website (Next lädt website/.env.development.local). Das Harness braucht den Composio-Schlüssel nicht. Richten Sie es vor dem Start auf die lokale Website aus, zum Beispiel OHARNESS_SITE_URL=http://localhost:4000 ./dev.sh up harness. up startet laufende Prozesse nicht neu; verwenden Sie restart website harness, nachdem Sie Ihre Arbeit gespeichert haben. Eine Änderung an der Cloud auf localhost bringt die API nicht auf die öffentliche Website.

Gesprächsablauf

1. Der Agent ruft cloud_app_tools auf, um Apps aufzulisten oder die genauen Tool-Schemas und die Version einer App zu ermitteln. Das ist schon verfügbar, bevor ein App-Konto verbunden ist.
2. Zuerst läuft die normale Berechtigungsrichtlinie von OHarness. Ist der Aufruf freigegeben, aber noch nicht gebunden, wartet das aktuelle Tool, und der Web-Chat zeigt Verbinden / Abbrechen.
3. Nur der Klick des Nutzers auf Verbinden fordert einen gehosteten Composio-Link an. Die Cloud setzt user_id aus der validierten Anmeldung, nie aus Modelleingaben.
4. Die Oberfläche öffnet die Autorisierungsseite. Der lokale Broker fragt die Cloud regelmäßig ab; die Cloud prüft bei Composio Kontoinhaber, Auth Config, Toolkit und den Zustand aktiv/nicht deaktiviert.
5. Ein verifizierter Erfolg löst das wartende Tool im selben Agent-Zug auf. Es ermittelt das Schema und ruft dann cloud_app_execute über die normale Berechtigungsschranke auf. Es entsteht weder eine doppelte Rückfrage an den Nutzer noch eine neue autonome Aufgabe.

Ein kostenloses Konto kann zwei Apps verbinden und nutzen; jeder kostenpflichtige Tarif – Plus eingeschlossen, persönlich oder für ein Team, ausgelesen aus dem ent-Claim des Sitzungstokens – hat kein Limit. Das Kontingent gilt für die zuerst verbundenen Apps: Das Verknüpfen einer dritten oder das Ausführen eines Tools einer App jenseits der ersten zwei (etwa nach Ablauf eines Tarifs) wird mit 402 plan_required abgelehnt, woraus das Harness eine Meldung mit Verweis auf die Preisseite macht. Apps auflisten und eine Verbindung prüfen ist nie begrenzt. Die Website setzt die Anzahl mit OHARNESS_FREE_CONNECTOR_APPS; eine selbst gehostete Website setzt OHARNESS_CONNECTORS_FREE=1, um das Limit für jedes angemeldete Konto aufzuheben.

Wird ein zuvor verbundenes Konto widerrufen, gibt execute vor der Ausführung eine ausdrückliche Ablehnung connection_required zurück, die denselben Ablauf auslöst. Timeouts, Anbieterfehler oder unklare Ausführungsfehler werden nie automatisch wiederholt. Ein Neuladen der Webseite stellt den Zustand ausstehender Karten wieder her, solange der Prozess läuft.

Sicherheit und Grenzen von V1

• Nur vier POST-Endpunkte für native Clients: catalog, status, link und execute. Auth-Links bleiben in den Antworten an die Oberfläche, außerhalb der Modellausgabe und der Verlaufsspeicherung.
• Ausstehende Interaktionen sind an den verifizierten Nutzer und den Cloud-Origin gebunden. Ein Wechsel der Anmeldung kann die Autorisierungsaufgabe eines alten Nutzers nicht gegen ein anderes Konto fortsetzen.
• Metadaten und Ausführung verwenden dieselbe konkrete Tool-Version. Löst latest nach einem Serverneustart anders auf, wird neu ermittelt, statt ein veraltetes Schema auszuführen. Verwenden Sie datierte Versionen für reproduzierbare Deployments.
• Abbrechen, Agent-Abbruch, Timeout nach zehn Minuten und Herunterfahren beenden den wartenden Aufruf. Eine abgebrochene Aufgabe macht eine unabhängig davon abgeschlossene OAuth-Freigabe nicht rückgängig.
• Keine Fortsetzung über einen Prozessneustart hinweg und keine Wiederholung von Hintergrundjobs. Beginnen Sie nach einem Neustart einen neuen Zug; eine bereits abgeschlossene Composio-Bindung bleibt auffindbar.
• V1 geht von einem aktiven Konto pro App, Auth Config und Nutzer aus. Mehrere aktive Konten schlagen fail-closed fehl, bis ein Admin eines auswählt. Keine geteilten Konten und keine ACL-Oberfläche.
• Karten werden derzeit im Web-Chat dargestellt (einschließlich der Web-Oberfläche der Desktop-App), nicht in Terminal- oder Headless-Oberflächen. Diese haben keine Karten-UI; verwenden Sie für die erste Bindung die Web-Oberfläche oder deaktivieren Sie dieses Plugin für unbeaufsichtigte bzw. Headless-Läufe.
• Jeder Prozess hat eine einfache Ratenbegrenzung. In Produktion müssen geteilte Limits am Edge, eine Audit- und Aufbewahrungsrichtlinie sowie passend eingeschränkte OAuth-Auth-Configs hinzukommen.

Verifizierung

npm run test:cloud-connectors deckt Abbruch im Broker, Nebenläufigkeit, Timeout, verweigerte Berechtigung und einen echten Agenten ab, der nach gemockter Autorisierung weiterarbeitet. npm run test:composio der Cloud deckt Zugehörigkeit, Allowlist, Version, Widerruf und das Verhalten ohne Wiederholung ab. node --conditions=oharness-source script/cloud-connector-ui-demo.ts startet eine isolierte Offline-Web-Demo; sie greift nie auf echtes Gmail zu. Echtes OAuth erfordert weiterhin die Zustimmung des Nutzers im Browser.