Connecter votre agent de code à votre Chrome

Configuration recommandée : pour tirer le meilleur de LaunchRepo, nous vous recommandons vivement d’utiliser toujours Claude Code CLI ou Codex CLI dans un terminal plutôt que l’application de bureau Claude ou Codex. C’est notre façon de travailler recommandée, pas une garantie de permissions différentes ni d’une exécution sans interruption.

Utilisez Chrome DevTools MCP via le débogage à distance de Chrome, avec une version LTS actuelle de Node.js, npm et Google Chrome. Le tableau de bord local enregistre vos résultats ; votre agent pilote Chrome. Commencez avec un seul worker et gardez sa connexion MCP ouverte pendant toute l’exécution. N’utilisez ni transport par extension de navigateur ni autre intégration de contrôle du navigateur.

Choisir votre configuration

• Chrome 144+ : l’auto-connexion fonctionne sous Windows, macOS et Linux.
• macOS : vérifiez les permissions du Terminal.
• Auto-connexion indisponible, ou worker séparé nécessaire : utilisez un profil dédié pour macOS, Windows ou Linux.
• Avant de soumettre : faites le test de connexion.

Vérifiez node --version, npm --version et chrome://version. Sous Windows, utilisez Node/npm et Chrome natifs Windows ; WSL demande une configuration de connexion à part.

Connecter le Chrome existant

1. Dans Chrome 144+, ouvrez chrome://inspect/#remote-debugging et activez le débogage à distance. Si ce réglage est absent, utilisez un profil dédié autorisé, décrit plus bas.
2. Enregistrez Chrome DevTools MCP dans les réglages MCP de votre agent. Cet exemple JSON générique vaut pour macOS/Linux ; votre agent peut utiliser un autre format de configuration :

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

Sous Windows, utilisez "command": "cmd" et ces arguments :

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

3. Déclenchez une action de navigateur anodine et approuvez l’invite de connexion de Chrome dans la fenêtre voulue. Faites ensuite le test ci-dessous.

Le premier appel télécharge le paquet. Une fois la configuration faite, figez une version testée. Voir la documentation officielle sur la configuration et la configuration des clients.

Profil dédié : choisir votre système d’exploitation

Lancez-le depuis votre espace de travail privé, hors des dossiers partagés ou synchronisés. Gardez le profil ignoré par Git : il contient des sessions connectées. Connectez-vous vous-même aux comptes nécessaires. Chrome 136+ exige un profil autre que celui par défaut pour ces flags de débogage.

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

Gardez le terminal de lancement ouvert. Dans les arguments MCP, remplacez --autoConnect par --browserUrl=http://127.0.0.1:9222 ; ne combinez jamais les deux. Gardez le port local et ne le tunnelisez jamais publiquement. Vérifiez l’écouteur : lsof -nP -iTCP:9222 -sTCP:LISTEN sur macOS, ss -ltnp 'sport = :9222' sur Linux, ou Get-NetTCPConnection -State Listen -LocalPort 9222 | Select-Object LocalAddress, OwningProcess sous Windows. Seules les adresses de bouclage sont acceptables. Si un autre programme occupe le port, choisissez-en un libre et mettez à jour les deux configurations. Ne tuez jamais des navigateurs sans rapport et ne supprimez jamais les verrous d’un profil actif.

Permissions macOS

Vérifiez l’application qui lance MCP : Terminal, iTerm ou votre éditeur ou application d’agent. Si macOS refuse l’accès à des fichiers Chrome protégés :

1. Ouvrez Réglages Système → Confidentialité et sécurité → Accès complet au disque.
2. Ajoutez cette application hôte réelle avec +, authentifiez-vous et activez-la.
3. Quittez complètement l’application puis rouvrez-la, reconnectez-vous et refaites le test.

Il s’agit d’une vérification de permission, pas d’une exigence universelle de CDP. Si la connexion fonctionne, n’accordez pas d’accès plus large sans nécessité. Une connexion CDP seule ne demande normalement aucune permission Accessibilité, Automatisation ou Enregistrement de l’écran. L’approbation de connexion propre à Chrome est distincte et peut revenir après un redémarrage.

Tester la connexion

Demandez à votre agent d’ouvrir https://example.com dans un nouvel onglet, de lire son titre et son titre principal, et d’identifier l’onglet utilisé. Regardez cette fenêtre. Un processus MCP en cours ne prouve rien à lui seul. Connectez-vous ensuite à l’annuaire cible et confirmez l’identité réelle à destination ; un OAuth réussi ne prouve pas à lui seul que la connexion a abouti. Vérifiez votre boîte mail dans les limites des permissions convenues.

Faites ensuite évaluer navigator.webdriver par l’agent dans ce même onglet. La valeur doit être false. Si elle vaut true, votre entrée MCP n’a pas --autoConnect (ou --browserUrl pour un profil dédié) et Chrome DevTools MCP a lancé son propre Chrome d’automatisation. Les contrôles anti-robots comme Cloudflare Turnstile restent alors bloqués sur « vérification » sans jamais afficher de défi que vous pourriez résoudre. Corrigez l’entrée, redémarrez la session de l’agent et refaites le test. Ne masquez jamais ce flag avec des flags ou scripts de dissimulation.

N’enregistrez que réussite/échec et des notes non sensibles dans onboarding.json ou SESSION.md. Ne copiez ni cookies, ni liens d’authentification, ni transcriptions du navigateur. Résolvez vous-même les CAPTCHA et la 2FA. Après un délai dépassé sur Submit, vérifiez la plateforme avant de réessayer. Si la mauvaise fenêtre bouge, arrêtez et vérifiez la connexion. Sans ce test, ces instructions ne peuvent pas certifier votre combinaison précise de système et d’agent.

Deux workers et fermeture des fenêtres

Le planificateur d’exécution démarre avec 10 soumissions et un seul worker navigateur. Un second worker est une option avancée que vous choisissez vous-même, seulement après avoir testé des navigateurs contrôlés séparément. Il lui faut alors sa propre attribution de plateforme, son propre profil Chrome, son port et sa connexion MCP. Par exemple, utilisez .browser/worker-1 sur 9222 et .browser/worker-2 sur 9223. Testez chacun indépendamment. Si l’hôte ne peut pas diriger les workers vers des connexions séparées, restez à un seul.

Donnez à chaque soumission une fenêtre dédiée. Après confirmation, enregistrez ses preuves et son résultat, puis fermez uniquement cette fenêtre et ses propres onglets de connexion et de vérification. Laissez ouverts les fenêtres personnelles, les boîtes mail partagées, le tableau de bord, les formulaires non enregistrés et les relais humains. Si MCP ne peut pas fermer la fenêtre, fermez ses propres onglets et consignez le nettoyage restant pour le propriétaire. Conservez le profil ; reconnectez-vous si la fermeture de la dernière fenêtre déconnecte MCP. Le guide d’onboarding explique l’étape suivante.