Il relay del browser di OpenClaw

Il tuo agente sa recuperare una pagina, ma recuperarla non equivale a usarla. La scheda che conta ha già l’accesso effettuato, si trova su un portatile in un’altra stanza, e il Gateway gira su un server completamente altrove. La risposta di OpenClaw è inoltrare le azioni del browser alla macchina su cui il browser si trova davvero, e poi mantenerle lì.

Quattro posti in cui può stare il browser

• Controllo locale, quello predefinito. Il Gateway avvia il servizio di controllo in loopback e può lanciare un browser locale. Le azioni senza destinazione come open, navigate o openclaw browser start possono lanciarlo; un’azione che indica una scheda tramite targetId, ID scheda o etichetta non avvia mai un browser fermo, perché un browser appena avviato non può contenere quella scheda.
• Controllo remoto tramite un node host. Esegui un node host sulla macchina che ha il browser, e il Gateway gli inoltra via proxy le azioni del browser. Il nodo espone il proprio server locale di controllo del browser tramite un comando proxy, quindi al Gateway non serve affatto il binario del browser.
• CDP remoto. Imposta la chiave cdpUrl sotto il tuo profilo in browser.profiles, o la chiave legacy a profilo singolo browser.cdpUrl, per collegarti a un browser remoto basato su Chromium. In quel caso OpenClaw non avvierà un proprio browser locale.
• Servizi loopback attach-only. Per un servizio CDP gestito esternamente e pubblicato su 127.0.0.1, di cui Browserless in Docker è il caso tipico, imposta anche attachOnly: true. Un CDP in loopback senza attachOnly viene trattato come un profilo locale gestito da OpenClaw, e OpenClaw potrebbe segnalare che la porta è in uso ma non appartiene a OpenClaw.

Una volta che un’azione raggiunge il nodo, lo snapshot o le impostazioni successive restano su quel nodo invece di cambiare browser.

L’instradamento si decide una volta, non per ogni azione

L’instradamento automatico preferisce l’host, compreso un browser gestito fermo il cui eseguibile è soltanto installato. Una destinazione esplicita node, un selettore di nodo o gateway.nodes.browser.node prevalgono su questa preferenza, mentre target=host resta sempre sull’host. Il proprietario selezionato, qualunque sia, poi tiene tutto: le connessioni existing-session, extension, attach-only e CDP remoto appartengono a lui anche quando non è presente alcun eseguibile di browser gestito, e gli errori di avvio, le impostazioni non valide dell’eseguibile, gli errori di permesso e gli errori delle azioni sulla pagina restano su quel proprietario invece di essere ripetuti su un’altra macchina. Il fallback automatico sull’host da un nodo selezionato è consentito solo prima che quel nodo abbia gestito una richiesta, ed è la frase qui sopra messa in pratica. È questo che rende coerente un’attività di browser in più passaggi: lo snapshot su cui agisci e i ref degli elementi che ha restituito descrivono un solo browser, non due.

I confini che il relay mantiene

• I profili vengono dalla configurazione browser.profiles del nodo stesso, esattamente come se fossi seduto davanti a quella macchina. Il Gateway non proietta il proprio elenco di profili sul nodo.
• Le modifiche persistenti ai profili vengono rifiutate tramite il comando proxy, comunque sia configurato: create-profile, delete-profile e reset-profile sono bloccati indipendentemente da allowProfiles. Fai queste modifiche direttamente sul nodo.
• nodeHost.browserProxy.allowProfiles è facoltativo. Se lo lasci vuoto, ogni profilo configurato resta raggiungibile tramite il proxy, che è il comportamento predefinito storico. Se lo imposti, OpenClaw lo tratta come un confine di privilegio minimo che limita i nomi di profilo a cui il proxy si rivolgerà. Per disattivare l’intero percorso, usa nodeHost.browserProxy.enabled=false sul nodo, oppure gateway.nodes.browser.mode=off sul Gateway, che accetta anche auto e manual.

L’agente vede un unico strumento per tutte e quattro le configurazioni: un solo strumento browser che copre doctor, status, start, stop, tabs, open, focus, close, snapshot, screenshot, navigate, act, requests, errors, text ed emulate, con un argomento profile per scegliere il browser e un argomento target con valore sandbox, host o node per scegliere la macchina. Lo stesso verbo può significare cose diverse a seconda della modalità. Stop su un profilo locale gestito termina il processo avviato da OpenClaw, mentre sui profili attach-only e CDP remoto chiude la sessione di controllo attiva e rilascia gli override di emulazione di Playwright e CDP per viewport, schema di colori, locale, fuso orario e modalità offline, anche se lì OpenClaw non ha mai avviato un processo del browser. L’impostazione headless segue la stessa regola, perché riguarda solo i profili locali gestiti che OpenClaw avvia. Trovi l’elenco completo delle azioni e dei loro argomenti nella guida alle azioni dello strumento browser, e cos’è davvero un node host, come si abbina e cos’altro può gestire lo spiega l’articolo sui nodi browser.

Browser ospitati e le tre forme di URL

OpenClaw accetta tre forme di URL CDP e sceglie automaticamente la strategia di connessione per ciascuna. Una base http:// o https:// significa rilevamento: OpenClaw chiama /json/version, legge l’URL del debugger WebSocket e si connette, senza fallback WebSocket. Un endpoint ws:// o wss:// diretto con un percorso /devtools/browser, page, worker, shared_worker o service_worker salta del tutto /json/version. Una radice WebSocket semplice senza percorso /devtools, che è ciò che ti forniscono Browserless e Browserbase, prova prima il rilevamento HTTP e ripiega su un handshake diretto alla radice se il rilevamento non restituisce nulla di utilizzabile. Questi URL di solito contengono l’autorizzazione come token nella query o credenziali HTTP Basic, e OpenClaw conserva questa autenticazione sia quando chiama gli endpoint /json/* sia quando apre il WebSocket CDP, quindi tratta l’intero URL come un segreto e tienilo in una variabile d’ambiente o in un gestore di segreti anziché in un file di configurazione. La diagnostica usa la stessa logica (prima il rilevamento, poi il fallback WebSocket) di una connessione a runtime, quindi l’API di controllo del browser non segnala come irraggiungibile una radice semplice che si connette. L’unica modalità con browser già autenticato che non ha affatto un cdpUrl è il relay dell’estensione Chrome: il relay possiede il proprio endpoint loopback e pilota schede reali senza nessuno al computer.

Su Diali

Diali ospita OpenClaw come servizio gestito. Ogni cliente ha il proprio assistente sul proprio runtime invece di un posto in un pool condiviso. La configurazione del runtime viene generata dalla tua dashboard e riscritta a ogni rilascio, quindi il blocco browser che imposti nell’interfaccia è quello con cui l’agente si avvia. Tutto ciò che l’agente conserva risiede su un volume persistente, con snapshot giornalieri e ripristino con un clic disponibili tramite il componente aggiuntivo Backup (incluso in Max). La pagina sull’hosting OpenClaw di Diali descrive il runtime ospitato e la pagina dei prezzi elenca i piani.

• Un node host inoltra le azioni del browser alla macchina che possiede il browser.
• Una volta che un’azione arriva su un nodo, il resto dell’attività resta lì.
• attachOnly evita che un servizio CDP in loopback venga scambiato per un profilo gestito.