Vai al contenuto principale
La scheda Aree di lavoro nell’interfaccia di controllo è uno spazio che tu e i tuoi agenti organizzate insieme. Le schede, i widget, le loro posizioni su una griglia a 12 colonne e i relativi collegamenti dati risiedono tutti in un unico documento. Qualsiasi elemento in grado di modificare tale documento può comporre l’area di lavoro: tu, la CLI openclaw workspaces o un agente che richiama gli strumenti workspace_*. Ogni scrittura segue lo stesso percorso convalidato, quindi il layout di un utente e quello di un agente non possono divergere. Ogni scrittura accettata incrementa una versione e trasmette plugin.workspaces.changed, così la modifica di un agente appare in un browser già aperto senza ricaricare la pagina.

​
Abilitare le aree di lavoro

Il Plugin Workspaces incluso è disabilitato per impostazione predefinita. Nell’interfaccia di controllo, apri Plugins, trova Workspaces e seleziona Enable. Puoi abilitarlo anche dalla CLI:
L’abilitazione del Plugin aggiunge la scheda Aree di lavoro e rende disponibili la CLI openclaw workspaces e gli strumenti per agenti workspace_*. La disabilitazione rimuove queste interfacce senza eliminare il database delle aree di lavoro o le risorse dei widget.

​
L’area di lavoro predefinita

Al primo caricamento viene visualizzata un’area di lavoro Panoramica: schede di costi e token, stato delle istanze, sessioni, stato Cron e un feed delle attività. Si tratta di normali contenuti dell’area di lavoro: trascinali, comprimili, nascondili o eliminali.

​
Widget integrati

Nove widget attendibili vengono distribuiti con il Plugin e sono visualizzati come interfaccia proprietaria: stat-card, markdown, table, iframe-embed, sessions, usage, cron, instances, activity. I widget dichiarano i dati tramite collegamenti e non li recuperano mai autonomamente: Il collegamento file è il modo più semplice per inserire i propri valori numerici in un’area di lavoro: scrivi un file JSON nella directory dei dati e indirizza un stat-card verso di esso.

​
Provenienza

Le schede e i widget includono un’indicazione createdBy — user, system o agent:<id> — impostata in base all’autore della scrittura. Il chiamante non può specificarla, quindi un agente non può attribuirti il proprio lavoro e il contrassegno “IA” su un widget creato da un agente indica sempre esattamente ciò che dichiara.

​
Widget personalizzati

Un agente può creare un vero widget HTML con workspace_widget_scaffold (oppure puoi farlo tu con openclaw workspaces widget-scaffold <name>). Il codice creato dagli agenti è considerato ostile:
  • Un widget generato viene inserito nel registro come in attesa. Non viene creato alcun iframe e la route delle risorse restituisce 404 per i relativi file finché un operatore non lo approva.
  • L’approvazione è una decisione distinta dalla modifica di un layout: workspaces.widget.approve richiede l’ambito operator.approvals, lo stesso che protegge le approvazioni di esecuzione.
  • Un widget approvato viene visualizzato in un <iframe sandbox="allow-scripts"> — mai allow-same-origin — quindi la sua origine è opaca e non può accedere al DOM, all’archiviazione o ai cookie del genitore.
  • Le sue risorse vengono fornite con connect-src 'none', bloccando le connessioni di rete degli script, come fetch, XHR e WebSocket. Non possiede credenziali e non comunica mai con il Gateway.
  • I dati lo raggiungono esclusivamente tramite un bridge postMessage con versione. Il codice personalizzato può ricevere i collegamenti static dichiarati, che sono valori dell’area di lavoro già creati da un agente o da un operatore. I collegamenti RPC e file rimangono nei widget integrati attendibili: i browser consentono a un elemento figlio in sandbox di navigare nel proprio frame, quindi i dati privilegiati non vengono mai inviati al codice HTML creato dagli agenti.
L’invio di un prompt nella chat da un widget richiede inoltre una funzionalità nel manifest, una conferma per ogni chiamata che riporti il testo esatto ed è soggetto a un limite di frequenza.

​
CLI

widget-approve richiede un dispositivo associato all’ambito operator.approvals; l’approvazione dall’interfaccia di controllo non lo richiede, perché il browser lo possiede già.

​
Archiviazione

Il documento dell’area di lavoro, il registro dei widget personalizzati e un anello di annullamento con 20 voci risiedono in <stateDir>/workspaces/workspaces.sqlite. Le risorse dei widget creati dagli agenti rimangono sul disco in <stateDir>/workspaces/widgets/<name>/ e i dati dei collegamenti file in <stateDir>/workspaces/data/, perché un agente li crea con normali strumenti per file e la route dei widget ne distribuisce i byte.