Cosa invia OpenClaw ai suoi server

Hai installato OpenClaw sulla tua macchina proprio perché nulla ne uscisse. Poi leggi una nota di rilascio, o guardi il log del firewall, e trovi una richiesta in uscita verso telemetry.openclaw.ai una volta al giorno. Vale la pena sapere esattamente cosa contiene quella richiesta, cosa conserva chi la riceve e quali parti puoi disattivare. La documentazione è insolitamente precisa su tutti e tre i punti.

Due livelli, e solo uno è attivo per impostazione predefinita

• Il controllo quotidiano degli aggiornamenti è il livello predefinito. È un semplice GET a https://telemetry.openclaw.ai/api/latest-version che chiede se esiste una versione più recente, e non ha alcun corpo di richiesta.
• Tutto ciò che comunica al server viaggia in un solo header. Uno User-Agent come openclaw/2026.8.2 (darwin; node/26.0.1; arm64; gateway) contiene la versione di OpenClaw, il sistema operativo, la versione di Node.js, l’architettura della CPU e se il chiamante era il Gateway o la CLI.
• Nessuno dei due livelli include il contenuto dei messaggi, prompt, nomi di modelli, chiavi API, credenziali, percorsi di file, nomi host o identificativi di account. Non c’è nemmeno un identificativo di installazione, un identificativo della macchina o un identificativo casuale di tracciamento: OpenClaw non crea alcun id client persistente per queste richieste, ed è per questo che i report ripetuti non sono un conteggio di installazioni o di utenti.
• Le statistiche anonime sulle funzionalità sono il secondo livello, e sono disattivate per impostazione predefinita. Quando le attivi, la stessa richiesta quotidiana diventa un POST con un piccolo corpo JSON alla versione di schema 1, invece di aggiungere una seconda richiesta.

Rifiutare è una scelta del tutto normale e non cambia nulla di come OpenClaw funziona per te.

Qui il consenso esplicito è davvero esplicito

La configurazione interattiva può proporre un opt-in una tantum con No thanks selezionato per impostazione predefinita, e il Quick Start guidato salta del tutto quella domanda. OpenClaw registra la tua risposta così la configurazione smette di chiedertelo, ma non è la risposta registrata a decidere: lo decide l’impostazione enabled. Le installazioni non interattive e da script non fanno mai l’opt-in da sole, quindi un’immagine costruita in una pipeline resta al livello del solo controllo degli aggiornamenti finché un operatore non attiva deliberatamente le statistiche. Lo scopo dichiarato del secondo livello è ristretto, orientare le priorità di manutenzione, e la documentazione dice esplicitamente che non misura nessuna singola invocazione di plugin, nessun messaggio, nessuna richiesta al modello e nessun utente attivo.

Il campo che il client non controlla

• Cloudflare fornisce al ricevitore ospitato una posizione approssimativa: paese, codice della regione, città e fuso orario. Nei dati analitici non vengono salvati indirizzi IP grezzi né coordinate precise, e i campi mancanti o non validi restano semplicemente vuoti.
• I controlli degli aggiornamenti registrati includono questi campi anche quando le statistiche anonime sulle funzionalità sono disattivate e anche quando DO_NOT_TRACK è impostato. Non entrano in gioco payload aggiuntivi del client né richieste di consenso, perché i valori vengono ricavati all’edge anziché inviati da te.
• Analytics Engine conserva i record per tre mesi. Gli aggregati pubblici escludono le informazioni sulla posizione, e disattivare le richieste in seguito non cancella i record già esistenti.

Prima di cambiare qualsiasi cosa, esegui openclaw telemetry show. Riporta se le statistiche anonime sulle funzionalità sono attive e perché, l’endpoint della richiesta e l’ultimo controllo riuscito, e quando le statistiche sono disattivate stampa la richiesta del solo controllo degli aggiornamenti insieme al suo header User-Agent. Aggiungi --json per avere lo stesso stato e lo stesso payload in un unico documento leggibile da una macchina. Quando le statistiche sono attive l’anteprima mostra l’intero payload, ed è breve: schema, version, platform, node, surface e un oggetto features che contiene gli id dei canali configurati, le famiglie di provider, gli id dei plugin pubblici, un conteggio totale dei plugin e sessionsLast24h. Quei nomi di plugin coprono i plugin inclusi, le installazioni ufficiali attendibili e le voci che corrispondono al catalogo ufficiale dei plugin, quindi le identità dei plugin privati non vengono mai nominate, e la differenza tra pluginsEnabled e il numero di nomi riportati non è un conteggio affidabile dei plugin privati. Il dato sulle sessioni conta gli eventi di creazione di sessione conservati con un timestamp nelle 24 ore precedenti, e non l’attività delle sessioni. Qui contano due limiti: l’anteprima del payload viene costruita dentro il processo della CLI anziché recuperata dal Gateway in esecuzione, quindi non garantisce l’esatto payload successivo del Gateway, e descrive solo la richiesta del client, quindi non può mai mostrarti la posizione ricavata dal server. Se l’output dice Request: none, un’automazione o una policy di controllo degli aggiornamenti ha già fermato tutto. La preferenza in sé è una normale chiave nel file di configurazione di OpenClaw, e non ha nulla a che vedere con il monitoraggio dell’utilizzo dei provider, che riguarda le quote e i costi dei provider.

Tutti i modi per disattivare le richieste

Il comando openclaw telemetry off disattiva le statistiche anonime sulle funzionalità, e telemetry.enabled: false fa la stessa cosa dal file di configurazione. DO_NOT_TRACK=1 o DO_NOT_TRACK=true forza la disattivazione delle statistiche anche quando telemetry.enabled è true, ma lascia deliberatamente attivo il controllo quotidiano degli aggiornamenti sotto forma di GET senza corpo. Per fermare ogni richiesta automatica, imposta update.checkOnStart: false, che disattiva entrambi i livelli e l’avviso di aggiornamento anche quando update.auto.enabled è true, e anche OPENCLAW_NO_AUTO_UPDATE=1 impedisce le richieste di aggiornamento automatico. OpenClaw inoltre non invia nulla quando la variabile d’ambiente CI ha un valore vero, con l’argomento che i job delle pipeline supererebbero di numero gli operatori reali e renderebbero privi di significato i conteggi di versioni e piattaforme, anche se impostare OPENCLAW_TELEMETRY_ENDPOINT su un tuo endpoint sostitutivo annulla questa soppressione, perché un endpoint configurato significa che l’esecuzione sta seguendo questo percorso di proposito. I comandi di aggiornamento espliciti restano disponibili ogni volta che scegli di eseguirli, quindi gli aggiornamenti intenzionali di OpenClaw restano nelle tue mani, e tutto questo si affianca naturalmente alle pratiche di sicurezza di OpenClaw.

Su Diali

OpenClaw ospitato su Diali è un servizio gestito. Ogni cliente ha un assistente separato sulla propria istanza anziché un posto su un’istanza condivisa, e la configurazione di esecuzione viene generata dalle impostazioni della tua dashboard e riscritta da zero a ogni release, quindi una modifica manuale fatta dentro il container non sopravvive a un aggiornamento, mentre tutto ciò che è espresso nella dashboard sì. Sessioni, memoria e il resto dello stato vivono su un volume persistente, che è anche il posto in cui si troverebbe il risultato in cache di un controllo degli aggiornamenti riuscito; snapshot giornalieri e ripristino con un clic sono disponibili tramite il componente aggiuntivo Backup (incluso nel piano Max). La pagina dei prezzi di Diali elenca i piani.

• Il controllo quotidiano degli aggiornamenti è attivo per impostazione predefinita e viaggia interamente in un solo header User-Agent.
• Le statistiche anonime sulle funzionalità restano disattivate finché un operatore non le attiva.
• La posizione approssimativa viene conservata per tre mesi, e disattivare le richieste non la cancella.