Passer au contenu principal
L’onglet Espaces de travail de l’interface de contrôle est une surface que vous et vos agents organisez ensemble. Les onglets, les widgets, leur position sur une grille à 12 colonnes et leurs liaisons de données sont tous regroupés dans un même document. Tout ce qui peut modifier ce document peut composer l’espace de travail : vous, la CLI openclaw workspaces ou un agent appelant les outils workspace_*. Chaque écriture suit le même processus validé, de sorte que la disposition d’un humain et celle d’un agent ne peuvent pas diverger. Chaque écriture acceptée incrémente une version et diffuse plugin.workspaces.changed ; la modification d’un agent apparaît donc dans un navigateur déjà ouvert sans rechargement.

​
Activer les espaces de travail

Le Plugin Espaces de travail inclus est désactivé par défaut. Dans l’interface de contrôle, ouvrez Plugins, recherchez Workspaces, puis sélectionnez Enable. Vous pouvez également l’activer depuis la CLI :
L’activation du Plugin ajoute l’onglet Espaces de travail et rend disponibles la CLI openclaw workspaces ainsi que les outils d’agent workspace_*. Sa désactivation supprime ces interfaces sans effacer la base de données des espaces de travail ni les ressources des widgets.

​
L’espace de travail par défaut

Lors du premier chargement, vous obtenez un espace de travail Vue d’ensemble : cartes de coûts et de jetons, état des instances, sessions, état des tâches Cron et flux d’activité. Il s’agit d’un contenu d’espace de travail ordinaire : déplacez-le, réduisez-le, masquez-le ou supprimez-le.

​
Widgets intégrés

Neuf widgets approuvés sont fournis avec le Plugin et s’affichent comme une interface native : stat-card, markdown, table, iframe-embed, sessions, usage, cron, instances, activity. Les widgets déclarent leurs données au moyen de liaisons ; ils ne les récupèrent jamais eux-mêmes : La liaison file est le moyen le plus simple d’ajouter vos propres chiffres à un espace de travail : écrivez un fichier JSON dans le répertoire de données et faites pointer une stat-card vers celui-ci.

​
Provenance

Les onglets et les widgets comportent une marque createdBy — user, system ou agent:<id> — définie selon l’auteur de l’écriture. L’appelant ne peut pas la fournir ; un agent ne peut donc pas présenter son travail comme le vôtre, et la pastille « IA » d’un widget créé par un agent signifie toujours exactement ce qu’elle indique.

​
Widgets personnalisés

Un agent peut créer un véritable widget HTML avec workspace_widget_scaffold (ou vous-même, avec openclaw workspaces widget-scaffold <name>). Le code créé par un agent est considéré comme hostile :
  • Un widget généré entre dans le registre avec l’état en attente. Aucune iframe n’est créée et la route des ressources renvoie une erreur 404 pour ses fichiers jusqu’à ce qu’un opérateur l’approuve.
  • L’approbation constitue une décision distincte de la modification d’une disposition : workspaces.widget.approve nécessite la portée operator.approvals, la même que celle qui protège les approbations d’exécution.
  • Un widget approuvé s’affiche dans un <iframe sandbox="allow-scripts"> — jamais avec allow-same-origin — de sorte que son origine est opaque et qu’il ne peut pas accéder au DOM, au stockage ni aux cookies du parent.
  • Ses ressources sont servies avec connect-src 'none', ce qui bloque les communications réseau des scripts telles que fetch, XHR et WebSockets. Il ne détient aucun identifiant d’accès et ne communique jamais avec le Gateway.
  • Les données ne lui parviennent que par l’intermédiaire d’un pont postMessage versionné. Le code personnalisé peut recevoir les liaisons static déclarées, qui sont déjà des valeurs d’espace de travail créées par un agent ou un opérateur. Les liaisons RPC et de fichiers restent dans les widgets intégrés approuvés : les navigateurs permettent à un enfant en bac à sable de faire naviguer sa propre iframe ; les données privilégiées ne sont donc jamais transmises au code HTML créé par un agent.
L’envoi d’une invite dans la discussion depuis un widget nécessite en outre une capacité dans le manifeste, une confirmation à chaque invocation citant le texte exact et est soumis à une limitation de débit.

​
CLI

widget-approve nécessite un appareil associé disposant de la portée operator.approvals ; l’approbation depuis l’interface de contrôle ne l’exige pas, car le navigateur la détient déjà.

​
Stockage

Le document de l’espace de travail, le registre des widgets personnalisés et un historique d’annulation de 20 entrées résident dans <stateDir>/workspaces/workspaces.sqlite. Les ressources des widgets créés par les agents restent sur le disque sous <stateDir>/workspaces/widgets/<name>/, et les données des liaisons de fichiers sous <stateDir>/workspaces/data/, car un agent les crée avec des outils de fichiers ordinaires et la route du widget sert leurs octets.