La Control UI di OpenClaw

Hai installato OpenClaw, avviato il Gateway e letto da qualche parte che esiste una dashboard nel browser. Per aprirla basta un URL, ma la pagina che si carica chiede un Gateway secret che nessuno ti ha dato, e l’indirizzo LAN stampato nel terminale potrebbe non rispondere affatto dal tuo portatile. Ecco cos’è davvero la Control UI, cosa accetta quell’unico campo e cosa fa l’elenco degli agenti che c’è dietro.

Cosa espone il Gateway sulla porta 18789

• La Control UI è una piccola single-page app Vite e Lit servita dal Gateway stesso, per impostazione predefinita su http://your-host:18789/, con un prefisso opzionale se imposti gateway.controlUi.basePath, ad esempio /openclaw. Comunica direttamente con il WebSocket del Gateway sulla stessa porta, quindi non c’è un secondo servizio da avviare né un host API separato a cui puntarla.
• Sull’host del Gateway, apri http://127.0.0.1:18789/ o http://localhost:18789/. Se la pagina non si carica proprio, avvia prima il Gateway con openclaw gateway.
• gateway.controlUi.enabled si applica a caldo. Disattivalo e il Gateway smette di servire le pagine e gli asset della dashboard, mentre i bot e le connessioni Gateway esistenti continuano a funzionare; riattivalo e il servizio riprende, con gli asset mancanti preparati in background. Cambiare il percorso base servito o la radice degli asset richiede comunque un riavvio del Gateway.
• Se l’URL LAN funziona sull’host ma non da un’altra macchina, sospetta dell’host prima che della rete. Con i bind LAN nativi di Windows, Windows Firewall o una Group Policy gestita dall’organizzazione possono bloccare l’URL LAN annunciato anche quando 127.0.0.1 funziona sull’host del Gateway, e openclaw gateway status --deep, eseguito su quell’host Windows, segnala le porte probabilmente bloccate, i profili non corrispondenti e le regole firewall locali che la policy potrebbe ignorare.

Una connessione loopback diretta non aggira l’autenticazione tramite token o password.

Perché la pagina sulla tua stessa macchina vuole comunque un segreto

L’autenticazione avviene durante l’handshake WebSocket, non in un modulo di accesso che l’app potrebbe saltare in silenzio per i visitatori locali. Il Gateway accetta il segreto condiviso configurato in connect.params.auth.token oppure in connect.params.auth.password, ed è gateway.auth.mode a stabilire quale valore configurato si applica; accetta anche gli header di identità di Tailscale Serve quando gateway.auth.allowTailscale è true, e gli header di identità di un proxy fidato quando gateway.auth.mode è trusted-proxy. L’autenticazione del Gateway avviene prima dell’abbinamento del dispositivo, quindi un browser dimostra chi è con il segreto condiviso prima ancora di poter inviare una richiesta di abbinamento. Un browser in loopback diretto può fare a meno del segreto condiviso solo quando gateway.auth.mode è impostato esplicitamente su none, il che disattiva del tutto l’autenticazione del gateway e non è la configurazione consigliata per la Control UI.

Un campo, due tipi di valore

• La schermata di accesso e Settings, poi Gateway, usano lo stesso unico campo Gateway secret: incolla il token o digita la password. Non è il browser a scegliere la modalità: l’ha già scelta gateway.auth.mode sull’host.
• Dopo una connessione riuscita, la UI conserva il segreto nel session storage, limitato alla scheda corrente del browser e all’origine del Gateway, e solo quando il Gateway segnala l’autenticazione tramite token. Le password restano in memoria e non vengono mai salvate in modo persistente, e una volta abbinato il dispositivo il browser può usare il token per dispositivo memorizzato nelle connessioni successive.
• Un codice di configurazione copiato da Devices, Pair device, Copy setup code è una credenziale diversa. Incollane uno in Gateway secret e la UI mostra un suggerimento in linea prima che tu ti connetta: quel codice va in Settings, poi Gateway, nell’app mobile di OpenClaw, mentre la Control UI vuole il token condiviso restituito da openclaw gateway auth-token --show, eseguito in un terminale interattivo sull’host del Gateway.

C’è uno stato che sembra un bug e non lo è. L’onboarding locale genera per impostazione predefinita un Gateway secret in modalità token, senza scelta tra token e password, e mantiene una modalità password già esistente; per configurare esplicitamente una password si usa --gateway-auth password o --gateway-password con il valore che scegli, e Tailscale Funnel richiede la modalità password. Ma se il Gateway si avvia in modalità token senza un token configurato, genera invece un token di runtime effimero per quel processo. Quel token non viene scritto nella configurazione, quindi non si può recuperare, e un browser in loopback che non lo ha viene rifiutato: il campo che hai davanti chiede un valore che non esiste in nessun posto in cui tu possa leggerlo. Per uscirne esegui openclaw doctor --generate-gateway-token, riavvia il Gateway, poi esegui openclaw gateway auth-token --show in un terminale interattivo e incolla l’output in Gateway secret; il doctor di OpenClaw spiega cos’altro può toccare quello strumento di riparazione, e la guida al Gateway descrive il processo a cui la porta appartiene fin dall’inizio.

L’elenco degli agenti e la modalità team

Apri Agents nella barra laterale, scegli All agents nel selettore degli agenti oppure visita /agents, e ottieni un elenco invece di una chat: una scheda per ogni agente configurato con identità, modello, stato di lavoro attuale, ultima attività e un’anteprima della sua chat principale, con gli agenti al lavoro in cima e subito dopo quelli attivi più di recente. Open chat porta alla sessione principale di quell’agente, Manage agents apre /settings/agents e New agent apre la chat del custodian, che consiglia un capo dello staff, un ricercatore, un redattore, un revisore o un piccolo team con tutti e quattro, usando gli stessi modelli di ruolo della CLI e aspettando l’approvazione dell’operatore prima di creare qualsiasi cosa. Scegliere Show all agents attiva la modalità team: le sessioni si raggruppano sotto intestazioni di agente comprimibili nell’ordine configurato dell’elenco, la riga superiore diventa un’intestazione dello spazio di lavoro con il nome visualizzato configurato del Gateway, e l’ambito di pagina condiviso passa per impostazione predefinita ad All agents, così Automations, Dashboards, Sessions, Tasks e Usage mostrano righe di più agenti con l’identità dell’agente associata. La modalità team è una preferenza del browser, disattivata per impostazione predefinita e ricordata per ciascun gateway in quel browser, quindi lo stesso Gateway raggiunto da un altro profilo o tramite l’accesso remoto a OpenClaw parte in modalità agente singolo finché non la attivi anche lì. Come diversi agenti isolati finiscano dentro un unico processo Gateway è un argomento a sé, trattato nella guida a più agenti in un unico Gateway.

Su Diali

Diali ospita OpenClaw, quindi la porta, il token e il certificato smettono di essere un tuo problema: ogni cliente fa girare il proprio assistente sulla propria istanza, e noi serviamo la Control UI in HTTPS su un indirizzo reale invece che su un URL LAN in chiaro. La configurazione di runtime viene generata dalla tua dashboard Diali e riscritta da zero a ogni rilascio, quindi ciò che gira corrisponde sempre a ciò che hai selezionato, e lo stato dell’agente risiede su un volume persistente, con snapshot giornalieri e ripristino con un clic disponibili tramite il componente aggiuntivo Backup (incluso in Max). OpenClaw ospitato su Diali descrive cosa include l’assistente ospitato, e la pagina dei prezzi di Diali elenca i piani.

• La dashboard è il Gateway stesso, su un’unica porta.
• Un browser in loopback ha comunque bisogno del segreto configurato.
• Un token di runtime effimero non si può mai rileggere.