Les bacs à sable OpenShell pour OpenClaw

Le bac à sable est la partie d’une plateforme d’agents qui décide de l’ampleur des dégâts qu’une mauvaise instruction peut causer. OpenClaw fournit déjà ses propres backends, et OpenShell est l’option pour les équipes qui préfèrent confier ce travail à un service géré, sur le même hôte ou ailleurs. Le plugin laisse la passerelle OpenClaw responsable de l’agent et des plugins côté hôte, et ne confie à l’autre côté que le cycle de vie du bac à sable et l’exécution des commandes. En échange, vous obtenez une séparation nette et une décision de configuration qui compte plus que toutes les autres.

Ce que fait le plugin

• OpenClaw délègue la création, la recherche, la suppression et les détails de connexion des bacs à sable à l’outil OpenShell en ligne de commande, puis exécute les commandes en SSH en réutilisant le même transport et le même pont de fichiers distant que le backend SSH générique.
• La passerelle OpenShell qui gère ces bacs à sable est distincte de la passerelle OpenClaw, elle peut les faire tourner en local avec Docker, Podman ou la virtualisation ou les placer sur une infrastructure séparée, et une passerelle locale ne demande aucun compte cloud.
• Le compte de service qui exécute la passerelle doit voir le même outil, le même enregistrement de passerelle, les mêmes identifiants et la même sélection d’espace de travail que votre shell interactif, car une variable de chemin ou d’espace de travail exportée dans un terminal n’atteint pas automatiquement un service d’arrière-plan.
• Les opérations ordinaires de l’outil utilisent par défaut un délai de cent vingt secondes, tandis que la création d’un bac à sable reçoit toujours au moins trois cents secondes pour que les constructions d’image et le provisionnement initial ne soient pas interrompus.

Gardez les clés API dans les fournisseurs OpenShell plutôt que de les ajouter aux variables d’environnement du bac à sable.

Miroir ou distant

Le mode miroir est celui par défaut et garde l’espace de travail local comme référence. Avant qu’une commande ne s’exécute, l’espace local est synchronisé dans le bac à sable, et une fois qu’elle se termine, l’espace distant est resynchronisé vers le local. Un verrou couvre l’envoi, la commande et le téléchargement complets, ou bien une lecture ou une modification de fichier complète et sa synchronisation, et des poignées de backend distinctes partagent ce verrou. Les vérifications de répertoire de travail inspectent les dossiers de l’hôte qui seront envoyés et relâchent le verrou avant de rendre la main, si bien qu’une vérification abandonnée ne peut pas bloquer les outils suivants. Le compromis est un envoi et un téléchargement à chaque tour d’exécution, et l’avertissement qui l’accompagne est que les éditeurs externes et les autres processus de passerelle ne participent pas au verrou, si bien qu’un téléchargement peut remplacer des modifications faites pendant qu’une commande tournait. Le mode distant inverse tout cela, car l’espace de travail distant est amorcé une seule fois depuis le local à la première utilisation, n’est jamais réamorcé dès qu’il contient du contenu, et ensuite les lectures, écritures, éditions et correctifs se font directement du côté distant sans rien renvoyer vers le local. L’initialisation est sérialisée par runtime distant, mais ensuite les commandes et les outils de fichiers peuvent se chevaucher, y compris d’un tour d’agent à l’autre, si bien qu’une commande d’arrière-plan peut finir par attendre un fichier écrit par un tour ultérieur. Le résumé donné par la référence est que le miroir convient aux flux de développement tandis que le distant convient aux agents de longue durée et à l’intégration continue, et que les modifications faites sur l’hôte après l’amorçage restent invisibles jusqu’à la recréation du bac à sable.

Recréer est destructeur

• Recréer une portée supprime l’espace de travail distant et laisse l’utilisation suivante en amorcer un neuf, ce qui réinitialise surtout l’environnement d’exécution en mode miroir mais détruit des fichiers distants faisant foi en mode distant.
• La recréation est nécessaire après avoir changé le backend, la source du bac à sable, le mode d’espace de travail, le fichier de politique, la liste des fournisseurs, les indicateurs de GPU ou de fournisseurs automatiques ou l’un des répertoires distants, et elle doit se faire tant que l’ancienne passerelle et l’ancien espace de travail sont encore sélectionnés.
• Les répertoires distants doivent être des chemins absolus sous les racines gérées du bac à sable ou de l’agent et ne doivent pas se chevaucher, et puisque les images standard non privilégiées ne peuvent souvent pas créer le répertoire d’agent par défaut, deux dossiers sans recouvrement sous la racine déjà accessible en écriture sont la réponse la plus simple.

En mode miroir, l’espace de travail est envoyé avant chaque l’exécution des commandes puis téléchargé ensuite, si bien que le coût est visible à chaque tour, alors que ce qu’une session en bac à sable a le droit d’exécuter reste une question distincte, tranchée par la politique des outils du bac à sable.

Pourquoi la frontière tient

Les notes de durcissement sont la partie la plus révélatrice de la page. Le pont de fichiers du mode miroir épingle la racine de l’espace de travail local et revérifie les chemins canoniques avant chaque lecture, écriture, création de dossier, suppression et renommage, en rejetant les liens symboliques en milieu de chemin, si bien qu’un échange de lien ou un espace de travail remonté ne peut pas rediriger l’accès hors de l’arbre mis en miroir. La synchronisation exclut aussi les données de gestion de version et les répertoires de hooks dans les deux sens, si bien que les identifiants de dépôt, l’historique et le code de hook de confiance restent sur l’hôte de la passerelle au lieu d’être copiés dans un bac à sable non fiable. Les entrées qui ne peuvent pas être représentées, comme les liens symboliques, les sockets et les tubes nommés, ne sont jamais copiées dans l’un ou l’autre espace, et les entrées existantes de ce type sur l’hôte survivent même si le bac à sable supprime ou remplace leurs dossiers. Rien de tout cela n’est décoratif, puisque c’est ce qui rend raisonnable de confier l’exécution à un bac à sable géré, et le même raisonnement vaut lorsque ce travail tourne sur une infrastructure distante. Les limites sont énoncées tout aussi clairement, dont l’absence de navigateur en bac à sable sur ce backend, un seul espace de travail OpenShell par instance du plugin, et des réglages propres à Docker qui ne s’appliquent tout simplement pas ici.

Sur Diali

Sur Diali, chaque client fait tourner son propre assistant. Les canaux sont connectés depuis le tableau de bord, la configuration d’exécution est générée à partir de celui-ci puis remplacée à chaque version, et l’état vit sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). OpenClaw hébergé sur Diali décrit la forme hébergée et La sécurité Diali couvre le reste.

• En miroir le local fait foi, en distant c’est le bac à sable.
• Recréer en mode distant supprime des fichiers qui n’existent qu’ici.
• Un service d’arrière-plan n’hérite pas de votre environnement shell.