Connecteurs cloud

connector-cloud est un plugin d'architecture OHarness, pas MCP. Cloud détient la clé de projet Composio et la configuration approuvée des applications et des outils. Les clients utilisent leur connexion OHarness ; les identifiants OAuth Gmail restent chez Composio, limités à l'identifiant d'utilisateur OHarness vérifié par le serveur. Aucune nouvelle table Supabase n'est nécessaire.

Configuration

Secret d'exécution du site Cloud : COMPOSIO_API_KEY. Jamais NEXT_PUBLIC_, et jamais dans le config.json, le plugins.json, le bundle navigateur ni le contexte du modèle de l'utilisateur.
Les applications activées sont déduites des Auth Configs du projet Composio, pas d'un fichier. Une Auth Config qui porte une restriction d'outils est une application activée, et cette restriction est sa liste d'autorisation : une nouvelle intégration est donc une action dans le tableau de bord plutôt qu'un déploiement. La déduction refuse plutôt que de supposer : une configuration qui ne restreint aucun outil est ignorée (Composio interprète l'absence de restriction comme tous les outils du toolkit), deux configurations activées pour un même toolkit n'en activent aucune, et les configurations désactivées, les identifiants inutilisables ou les noms d'outils mal formés écartent l'application concernée. Les plafonds de 20 applications et 40 outils ne changent pas. L'ensemble est résolu une fois par processus : redémarrez donc Cloud après une modification dans le tableau de bord.
Le website/connectors.json de Cloud est désormais facultatif et ne peut que restreindre : {"disabled": ["slug"]} retire une application sans toucher à Composio. Un fichier qui contient encore toolkits conserve l'ancien comportement explicite. Le déploiement peut faire pointer OHARNESS_CONNECTORS_FILE vers un chemin absolu monté à la place. Il est volontairement ignoré par Git : incluez-le ou montez-le seulement si vous l'utilisez.
L'environnement Supabase existant du site valide les tokens de connexion OHarness.
cloud.json côté client : { "siteUrl": "http://localhost:4000" } facultatif pour le développement local ; par défaut, l'adresse publique de Cloud. Changer d'origine Cloud peut obliger à se reconnecter. OHARNESS_SITE_URL est une autre façon de la remplacer.
plugins.json côté client : le plugin par défaut ne nécessite aucune entrée. Pour le désactiver : { "runtimePlugins": [{ "id": "connector-cloud", "enabled": false }] }.

Créez l'Auth Config OAuth Gmail dans le tableau de bord Composio, pour le même projet que la clé API. Vérifiez ses scopes et utilisez un accès Gmail en lecture seule pour les tâches de lecture ; la liste d'autorisation d'exécution ne remplace pas des scopes OAuth réduits au strict nécessaire. La configuration d'exemple contient des valeurs fictives, pas des identifiants fonctionnels.

Avec OHarness_Cloud/dev.sh, définissez les variables Cloud sur le processus website (Next charge website/.env.development.local). Le harnais n'a pas besoin de la clé Composio. Faites-le pointer vers le site local avant de le démarrer, par exemple OHARNESS_SITE_URL=http://localhost:4000 ./dev.sh up harness. up ne redémarre pas les processus en cours ; utilisez restart website harness après avoir enregistré votre travail. Une modification de Cloud en localhost ne déploie pas l'API sur le site public.

Déroulement de la conversation

L'agent appelle cloud_app_tools pour lister les applications ou découvrir les schémas et la version exacts des outils d'une application. L'outil est disponible avant même qu'un compte d'application soit connecté.
La politique de permission habituelle d'OHarness s'applique d'abord. Si l'appel est approuvé et non lié, l'outil en cours attend et le chat Web affiche Connect / Cancel.
Seul le clic de l'utilisateur sur Connect demande un lien hébergé Composio. Cloud définit user_id à partir de la connexion validée, jamais à partir de l'entrée du modèle.
L'interface ouvre la page d'autorisation. Le broker local interroge Cloud ; Cloud vérifie chez Composio le propriétaire du compte, l'Auth Config, le toolkit et l'état actif/non désactivé.
Un succès vérifié débloque l'outil en attente dans le même tour d'agent. Il découvre le schéma, puis invoque cloud_app_execute en passant par le contrôle de permission habituel. Aucune demande en double à l'utilisateur ni nouvelle tâche autonome n'est créée.

Un compte gratuit peut connecter et utiliser deux applications ; toute offre payante — Plus comprise, personnelle ou d'équipe, lue dans la claim ent du token de session — n'a pas de limite. Le quota revient aux premières applications connectées : lier une troisième application, ou exécuter un outil d'une application au-delà des deux premières (par exemple après l'expiration d'une offre), est refusé avec 402 plan_required, que le harnais transforme en message indiquant la page des tarifs. Lister les applications et vérifier une connexion ne sont jamais limités. Le site fixe ce nombre avec OHARNESS_FREE_CONNECTOR_APPS ; un site auto-hébergé définit OHARNESS_CONNECTORS_FREE=1 pour lever la limite pour tous les comptes connectés.

Si un compte connecté auparavant est révoqué, l'exécution renvoie un refus explicite connection_required avant exécution, ce qui relance ce même déroulement. Les délais dépassés, les erreurs du fournisseur ou les échecs d'exécution incertains ne sont jamais rejoués automatiquement. Actualiser la page Web rejoue l'état des cartes en attente tant que le processus est actif.

Sécurité et limites de la V1

Seulement quatre endpoints POST pour les clients natifs : catalog, status, link et execute. Les liens d'autorisation restent dans les réponses de l'interface, hors de la sortie du modèle et du stockage des transcriptions.
Les interactions en attente fixent l'utilisateur vérifié et l'origine Cloud. Changer de connexion ne permet pas de reprendre la tâche d'autorisation d'un ancien utilisateur sur un autre compte.
Les métadonnées et l'exécution utilisent la même version concrète de l'outil. Si latest se résout différemment après un redémarrage du serveur, redécouvrez plutôt que d'exécuter un schéma périmé. Utilisez des versions datées pour des déploiements reproductibles.
L'annulation, l'arrêt de l'agent, le délai de dix minutes et l'extinction interrompent l'appel en attente. Une tâche annulée n'annule pas une autorisation OAuth accordée indépendamment.
Pas de reprise après redémarrage du processus ni de rejeu de tâche en arrière-plan. Après un redémarrage, commencez un nouveau tour ; une liaison Composio déjà finalisée reste découvrable.
La V1 suppose un seul compte actif par application/Auth Config/utilisateur. Plusieurs comptes actifs entraînent un refus par défaut en attendant une sélection par un administrateur. Pas de comptes partagés ni d'interface de gestion des ACL.
Les cartes s'affichent actuellement dans le chat Web (y compris la surface Web de l'application de bureau), pas dans les interfaces terminal ou headless. Celles-ci n'ont pas d'interface de cartes ; utilisez le Web pour la première liaison, ou désactivez ce plugin pour les exécutions sans surveillance ou en mode headless.
Chaque processus a une limitation de débit basique. La production doit ajouter des limites partagées en périphérie, une politique d'audit et de conservation, et configurer des Auth Configs OAuth aux scopes adaptés.

Vérification

npm run test:cloud-connectors couvre l'annulation du broker, la concurrence, les délais dépassés, le refus de permission et un véritable agent qui reprend après une autorisation simulée. Le npm run test:composio de Cloud couvre la propriété, la liste d'autorisation, la version, la révocation et l'absence de nouvelle tentative. node --conditions=oharness-source script/cloud-connector-ui-demo.ts démarre une démo Web isolée et hors ligne ; elle n'accède jamais au vrai Gmail. La vraie OAuth exige toujours le consentement de l'utilisateur dans le navigateur.

← Plugin Composio Mémoire et synchronisation →