Collega il tuo coding agent al tuo Chrome

Configurazione consigliata: per ottenere i risultati migliori con LaunchRepo, ti consigliamo vivamente di usare sempre Claude Code CLI o Codex CLI in un terminale, anziché l’app desktop di Claude o di Codex. È il workflow che consigliamo, non una garanzia di permessi diversi o di un’esecuzione senza interruzioni.

Usa Chrome DevTools MCP tramite il debug remoto di Chrome, con una versione LTS attuale di Node.js, npm e Google Chrome. La dashboard locale salva i tuoi record; il tuo agente controlla Chrome. Inizia con un solo worker e tieni aperta la sua connessione MCP per tutta la run. Non usare trasporti basati su estensioni del browser né integrazioni alternative per il controllo del browser.

Scegli la tua configurazione

• Chrome 144+: l’auto-connect funziona su Windows, macOS e Linux.
• macOS: controlla i permessi del Terminale.
• Auto-connect non disponibile, o serve un worker separato: usa un profilo dedicato per macOS, Windows o Linux.
• Prima di inviare: esegui il test di connessione.

Controlla node --version, npm --version e chrome://version. Su Windows usa Node/npm e Chrome nativi di Windows; WSL richiede una configurazione della connessione a parte.

Collega il Chrome che usi già

1. In Chrome 144+, apri chrome://inspect/#remote-debugging e attiva il debug remoto. Se l’opzione non c’è, usa uno dei profili dedicati consentiti descritti più sotto.
2. Registra Chrome DevTools MCP nelle impostazioni MCP del tuo agente. Questo esempio JSON generico vale per macOS/Linux; il tuo agente potrebbe usare un formato di configurazione diverso:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect", "--no-usage-statistics", "--no-performance-crux"]
    }
  }
}

Su Windows, usa "command": "cmd" e questi argomenti:

["/c", "npx", "-y", "chrome-devtools-mcp@latest", "--autoConnect", "--no-usage-statistics", "--no-performance-crux"]

3. Fai eseguire un’azione innocua nel browser e approva la richiesta di connessione di Chrome nella finestra prevista. Poi esegui il test descritto più sotto.

La prima invocazione scarica il pacchetto. Dopo la configurazione, fissa una versione che hai testato. Consulta la documentazione ufficiale su configurazione e configurazione dei client.

Profilo dedicato: scegli il sistema operativo

Esegui i comandi dal tuo workspace privato, fuori da cartelle condivise o sincronizzate. Fai ignorare il profilo a Git: contiene i tuoi accessi. Accedi tu stesso agli account necessari. Chrome 136+ richiede un profilo diverso da quello predefinito per questi flag di debug.

macOS

mkdir -p .browser/chrome
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-address=127.0.0.1 \
  --remote-debugging-port=9222 \
  --user-data-dir="$PWD/.browser/chrome" about:blank

Windows PowerShell

$launchrepoChrome = @(
  "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
  "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
  "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
) | Where-Object { Test-Path $_ } | Select-Object -First 1
if (-not $launchrepoChrome) { throw 'Locate Google Chrome first' }
New-Item -ItemType Directory -Force '.browser/chrome' | Out-Null
$launchrepoProfile = (Resolve-Path '.browser/chrome').Path
Start-Process -FilePath $launchrepoChrome -ArgumentList "--remote-debugging-address=127.0.0.1 --remote-debugging-port=9222 --user-data-dir=`"$launchrepoProfile`" about:blank"

Linux

launchrepo_chrome=$(command -v google-chrome || command -v google-chrome-stable)
if [ -z "$launchrepo_chrome" ]; then
  echo "Install or locate Google Chrome first."
else
  mkdir -p .browser/chrome
  "$launchrepo_chrome" \
    --remote-debugging-address=127.0.0.1 \
    --remote-debugging-port=9222 \
    --user-data-dir="$PWD/.browser/chrome" about:blank
fi

Lascia aperto il terminale da cui hai avviato Chrome. Negli argomenti MCP sostituisci --autoConnect con --browserUrl=http://127.0.0.1:9222; non combinarli mai. Tieni la porta in locale e non esporla mai pubblicamente tramite un tunnel. Verifica chi è in ascolto: lsof -nP -iTCP:9222 -sTCP:LISTEN su macOS, ss -ltnp 'sport = :9222' su Linux oppure Get-NetTCPConnection -State Listen -LocalPort 9222 | Select-Object LocalAddress, OwningProcess su Windows. Sono accettabili solo indirizzi di loopback. Se la porta è occupata da un altro programma, scegline una libera e aggiorna entrambe le configurazioni. Non chiudere mai forzatamente browser estranei e non cancellare i lock di profili attivi.

Permessi di macOS

Individua l’app che avvia MCP: Terminale, iTerm oppure l’app del tuo editor o agente. Se macOS nega l’accesso ai file protetti di Chrome:

1. Apri Impostazioni di Sistema → Privacy e sicurezza → Accesso completo al disco.
2. Aggiungi proprio quell’app con +, autenticati e attivala.
3. Chiudi completamente l’app e riaprila, ricollegati e ripeti il test.

È una verifica dei permessi, non un requisito universale di CDP. Se la connessione funziona, non concedere accessi più ampi senza motivo. Una connessione solo CDP di norma non richiede i permessi di Accessibilità, Automazione o Registrazione schermo. L’approvazione della connessione in Chrome è una cosa separata e può ripresentarsi dopo un riavvio.

Testa la connessione

Chiedi al tuo agente di aprire https://example.com in un nuovo tab, leggerne il titolo e l’intestazione principale e identificare il tab. Tieni d’occhio quella finestra. Un processo MCP in esecuzione, da solo, non dimostra nulla. Poi accedi alla directory di destinazione e verifica l’identità effettiva con cui sei entrato: un OAuth andato a buon fine non basta a dimostrare il login. Controlla la casella di posta entro i permessi concordati.

Poi fai valutare all’agente navigator.webdriver sullo stesso tab. Deve essere false. Se è true, nella voce MCP manca --autoConnect (o --browserUrl per un profilo dedicato) e Chrome DevTools MCP ha avviato un proprio Chrome di automazione. I controlli anti-bot come Cloudflare Turnstile restano allora su “verifica” all’infinito e non mostrano mai una sfida da risolvere. Correggi la voce, riavvia la sessione dell’agente e ripeti il test. Non nascondere mai il flag con flag o script stealth.

Salva in onboarding.json o SESSION.md solo l’esito (superato/non superato) e note non sensibili. Non copiare cookie, link di autenticazione o trascrizioni del browser. CAPTCHA e 2FA li completi tu. Dopo un timeout sul pulsante di invio, controlla la piattaforma prima di riprovare. Se si muove la finestra sbagliata, fermati e controlla la connessione. Senza questo test, queste istruzioni non possono garantire che la tua specifica combinazione di sistema operativo e agente funzioni.

Due worker e pulizia delle finestre

Il pianificatore delle run parte da 10 invii e al massimo 2 worker. Ogni worker ha bisogno di una piattaforma assegnata distinta, di un proprio profilo Chrome, di una propria porta e di una propria connessione MCP. Per esempio, usa .browser/worker-1 sulla 9222 e .browser/worker-2 sulla 9223. Testa ciascuno separatamente. Se l’host non riesce a instradare i worker su connessioni separate, usane uno solo.

Dai a ogni invio una finestra dedicata. Dopo la conferma, salva prove ed esito, poi chiudi solo quella finestra e i tab di login o di verifica che le appartengono. Lascia aperte le finestre personali, le caselle di posta condivise, la dashboard, i moduli non salvati e i passaggi di consegne a una persona. Se MCP non riesce a chiudere la finestra, chiudi i tab che le appartengono e annota ciò che resta da ripulire a cura del titolare. Conserva il profilo; ricollegati se la chiusura dell’ultima finestra disconnette MCP. La guida all’onboarding spiega il passo successivo.