Failed to start Chrome CDP on port 18800

Chiedi all’agente di aprire una pagina e la chiamata allo strumento torna con una sola riga di JSON: Failed to start Chrome CDP on port 18800 for profile openclaw. Niente in quel messaggio dice quale parte non ha funzionato, e su una macchina Linux headless il browser non compare mai. La causa abituale non è OpenClaw, è il browser che apt ha installato per te.

Quattro messaggi di errore, quattro cause diverse

• Failed to start Chrome CDP on port 18800 for profile openclaw significa che il profilo gestito non riesce ad avviarsi sulla sua porta di debug. Su Ubuntu il motivo abituale è che il Chromium presente sulla macchina è un wrapper snap e non un vero binario del browser.
• The profile appears to be in use by another Chromium process indica file di lock Singleton rimasti nella directory del profilo gestito. OpenClaw rimuove quei lock e riprova una volta quando il lock indica un processo morto sull’host corrente, ma i lock che indicano un altro hostname vengono conservati finché non confermi che il profilo non è più in uso, anche dopo aver rinominato la macchina.
• Missing X server or $DISPLAY significa che è stato richiesto esplicitamente un browser visibile su un host senza sessione desktop. I profili gestiti locali passano già alla modalità headless su Linux quando DISPLAY e WAYLAND_DISPLAY non sono impostati, quindi vedere questo errore significa che qualcosa ha forzato un browser con interfaccia grafica: OPENCLAW_BROWSER_HEADLESS=0, browser.headless impostato su false, o la stessa chiave su un singolo profilo.
• L’errore Port N is in use for profile NAME but not by openclaw compare quando è già configurato un servizio CDP esterno in loopback e attachOnly è ancora false. La soluzione è smettere di chiedere a OpenClaw di avviare un proprio browser, cioè la strada attach-only descritta più avanti.

Il confinamento AppArmor di snap interferisce con il modo in cui OpenClaw avvia e monitora il processo del browser.

Perché apt install chromium è la causa di fondo

Su Ubuntu e sulla maggior parte delle distribuzioni Linux, apt install chromium non ti dà un browser. Il pacchetto si risolve in chromium-browser, apt stampa una nota per dire che ha selezionato chromium-browser al posto di chromium, e quello che arriva sul disco è un wrapper snap. Questo conta, perché quando OpenClaw avvia un browser in locale prende il primo che trova nell’ordine Chrome, Brave, Edge, Chromium, Chrome Canary, e il suo percorso di ricerca su Linux copre /usr/bin, /snap/bin, /opt/google, /opt/brave.com, /usr/lib/chromium e /usr/lib/chromium-browser, più il Chromium gestito da Playwright in PLAYWRIGHT_BROWSERS_PATH o ~/.cache/ms-playwright. Su un server appena installato, dove lo snap è l’unico binario della famiglia Chromium presente, il rilevamento trova proprio quello e ogni avvio gestito si blocca lì. Nessuna combinazione di flag risolve il problema, ed è per questo che la risposta documentata è un binario diverso e non un’impostazione diversa.

Tre mosse che lo risolvono

• Installa il vero Google Chrome, che è la soluzione consigliata. Scarica google-chrome-stable_current_amd64.deb da dl.google.com, installalo con dpkg -i ed esegui sudo apt --fix-broken install -y se le dipendenze danno errori. Poi imposta browser.executablePath su /usr/bin/google-chrome-stable in ~/.openclaw/openclaw.json, con enabled, headless e noSandbox tutti a true.
• Se Chromium in snap deve restare, usa la modalità attach-only. Imposta browser.attachOnly su true così OpenClaw non avvia mai nulla, e avvia tu stesso il browser con chromium-browser --headless --no-sandbox --disable-gpu --remote-debugging-port=18800 --user-data-dir=$HOME/.openclaw/browser/openclaw/user-data about:blank.
• Fai sopravvivere quel browser avviato a mano alla tua shell con un servizio utente systemd. Un’unità in ~/.config/systemd/user/openclaw-browser.service che esegue /snap/bin/chromium con gli stessi flag, più Restart=on-failure e RestartSec=5, abilitata con systemctl --user enable --now openclaw-browser.service, tiene la porta CDP in ascolto prima che OpenClaw la richieda.

La configurazione si riduce a sei impostazioni, e i valori predefiniti sono pensati per un portatile più che per un server. browser.enabled attiva il controllo del browser ed è già true. browser.executablePath è il percorso di un binario basato su Chromium (Chrome, Brave, Edge o Chromium), rilevato automaticamente se lo ometti, con preferenza per il browser predefinito del sistema operativo quando quel browser è basato su Chromium. browser.headless esegue il browser senza interfaccia grafica ed è false per impostazione predefinita, quindi su un server va impostato esplicitamente, con OPENCLAW_BROWSER_HEADLESS disponibile come override per processo, non impostato di default. browser.noSandbox aggiunge il flag --no-sandbox di cui alcune configurazioni Linux hanno bisogno, predefinito false, e browser.attachOnly impedisce del tutto a OpenClaw di avviare un browser, predefinito false. La modalità attach-only è anche la risposta documentata su un Raspberry Pi, su un host VPS più datato o con uno storage lento, dove Chrome ha bisogno di più tempo per esporre il suo endpoint HTTP CDP di quanto consenta la scadenza prevista per il browser gestito. OpenClaw su Linux copre l’installazione su Linux in generale, e OpenClaw su un VPS è la checklist per un server senza nessuno davanti.

Errore di avvio CDP o blocco della navigazione

Con il browser configurato, verificalo prima di cercare altrove. Questi controlli vanno al servizio di controllo del browser di OpenClaw e non alla porta CDP di Chrome usata all’avvio, e la sua porta deriva da gateway.port: 18791 per impostazione predefinita, cioè la porta del gateway più due, quindi adattala se hai spostato il Gateway. Richiedi il percorso radice con curl e ottieni running, pid e chosenBrowser; invia un POST a /start; poi un GET a /tabs. Ora percorri la scala che separa le due classi di errore: openclaw browser --browser-profile openclaw start, poi tabs, poi open https://example.com. Se start fallisce con not reachable after start, il piano di controllo non è in salute ed è la disponibilità di CDP che devi inseguire. Se start riesce e tabs fallisce, è ancora un problema di raggiungibilità, non un problema della pagina. Se start e tabs passano entrambi e falliscono solo open o navigate, il browser è sano e stai guardando la policy di navigazione o la pagina stessa, che è un percorso di codice separato: la configurazione del browser usa per impostazione predefinita un oggetto di policy SSRF restrittivo (fail-closed) anche se non hai mai scritto browser.ssrfPolicy, e uno start o un tabs riusciti non concedono nulla all’indirizzo successivo. Quando serve un’eccezione, una voce ristretta con il nome host esatto in allowedHostnames è meglio che aprire la rete privata, e dangerouslyAllowPrivateNetwork va usato solo in un ambiente che hai esaminato di proposito. Lo strumento browser di OpenClaw è ciò che l’agente chiama davvero, e l’API di controllo del browser è il riferimento completo per l’API e la riga di comando.

Su Diali

Diali ospita OpenClaw, quindi questa serata a te non capita. Ogni cliente esegue il proprio assistente e non una quota di uno condiviso, e la configurazione di esecuzione viene generata da ciò che imposti nella dashboard, poi riscritta a ogni release, quindi non c’è nessun openclaw.json su un server da riparare dopo un aggiornamento e nessuna scelta tra snap e deb da fare. Tutto ciò che l’assistente conserva vive su un volume persistente, con snapshot giornalieri e ripristino con un clic disponibili tramite il componente aggiuntivo Backup (incluso nel piano Max). OpenClaw ospitato su Diali descrive la configurazione ospitata e la pagina dei prezzi di Diali indica quanto costa.

• apt install chromium ti dà un wrapper snap, non un browser.
• Prima il vero Chrome, poi attach-only più un’unità systemd.
• start e tabs passano ma open fallisce: è la policy, non CDP.