Deinen Coding-Agenten mit deinem Chrome verbinden

Empfohlenes Setup: Für die besten Ergebnisse mit LaunchRepo empfehlen wir dringend, immer Claude Code CLI oder Codex CLI im Terminal zu nutzen statt der Desktop-App von Claude oder Codex. Das ist unser empfohlener Arbeitsablauf, keine Garantie für andere Berechtigungen oder eine unterbrechungsfreie Ausführung.

Nutze Chrome DevTools MCP über das Remote-Debugging von Chrome, mit einer aktuellen Node.js-LTS-Version, npm und Google Chrome. Das lokale Dashboard speichert deine Einträge; dein Agent steuert Chrome. Beginne mit einem Worker und halte dessen MCP-Verbindung während des Laufs offen. Verwende keine Transporte über Browser-Erweiterungen und keine alternativen Integrationen zur Browser-Steuerung.

Wähle dein Setup

• Chrome 144+: Auto-Connect funktioniert unter Windows, macOS und Linux.
• macOS: Prüfe die Terminal-Berechtigungen.
• Auto-Connect nicht verfügbar oder ein separater Worker nötig: Nutze ein eigenes Profil für macOS, Windows oder Linux.
• Vor dem Einreichen: Führe den Verbindungstest durch.

Prüfe node --version, npm --version und chrome://version. Unter Windows nutzt du natives Windows-Node/npm und Chrome; WSL braucht ein eigenes Verbindungs-Setup.

Bestehendes Chrome verbinden

1. Öffne in Chrome 144+ chrome://inspect/#remote-debugging und aktiviere Remote-Debugging. Fehlt die Einstellung, nutze eines der unten beschriebenen zulässigen eigenen Profile.
2. Registriere Chrome DevTools MCP in den MCP-Einstellungen deines Agenten. Dieses generische JSON-Beispiel gilt für macOS/Linux; dein Agent kann ein anderes Konfigurationsformat verwenden:

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

Unter Windows verwendest du "command": "cmd" und diese Argumente:

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

3. Löse eine harmlose Browser-Aktion aus und bestätige die Verbindungsabfrage von Chrome im vorgesehenen Fenster. Führe dann den Test unten durch.

Der erste Aufruf lädt das Paket herunter. Pinne nach dem Setup eine getestete Version. Siehe die offizielle Konfiguration und das Client-Setup.

Eigenes Profil: wähle dein Betriebssystem

Führe die Befehle aus deinem privaten Workspace aus, außerhalb gemeinsam genutzter oder synchronisierter Ordner. Lass Git das Profil ignorieren: Es enthält Anmeldungen. Melde dich selbst bei den nötigen Konten an. Seit Chrome 136 ist für diese Debugging-Flags ein Profil abseits des Standardprofils Pflicht.

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

Lass das Terminal, aus dem du Chrome gestartet hast, offen. Ersetze in den MCP-Argumenten --autoConnect durch --browserUrl=http://127.0.0.1:9222; kombiniere die beiden nie. Halte den Port lokal und tunnele ihn nie öffentlich. Prüfe den Listener: lsof -nP -iTCP:9222 -sTCP:LISTEN unter macOS, ss -ltnp 'sport = :9222' unter Linux oder Get-NetTCPConnection -State Listen -LocalPort 9222 | Select-Object LocalAddress, OwningProcess unter Windows. Nur Loopback-Adressen sind zulässig. Belegt ein anderes Programm den Port, wähle einen freien und passe beide Konfigurationen an. Beende nie unbeteiligte Browser und lösche keine aktiven Profil-Locks.

macOS-Berechtigungen

Prüfe die App, die MCP startet: Terminal, iTerm oder deine Editor- bzw. Agenten-App. Verweigert macOS den Zugriff auf geschützte Chrome-Dateien:

1. Öffne Systemeinstellungen → Datenschutz & Sicherheit → Festplattenvollzugriff.
2. Füge genau diese Host-App mit + hinzu, authentifiziere dich und aktiviere sie.
3. Beende die App vollständig, öffne sie erneut, verbinde neu und wiederhole den Test.

Das ist eine Berechtigungsprüfung, keine allgemeine CDP-Voraussetzung. Funktioniert die Verbindung, erteile keine unnötig weitreichenden Rechte. Eine reine CDP-Verbindung braucht normalerweise weder Bedienungshilfen noch Automation noch Bildschirmaufnahme. Die Verbindungsfreigabe von Chrome ist davon getrennt und kann nach einem Neustart erneut erscheinen.

Die Verbindung testen

Bitte deinen Agenten, https://example.com in einem neuen Tab zu öffnen, Titel und Hauptüberschrift zu lesen und den Tab zu benennen. Beobachte dieses Fenster. Ein laufender MCP-Prozess allein beweist nichts. Melde dich danach beim Zielverzeichnis an und bestätige die tatsächliche Identität am Ziel; ein erfolgreiches OAuth allein beweist keine Anmeldung. Prüfe dein Postfach im Rahmen der vereinbarten Berechtigungen.

Lass den Agenten dann navigator.webdriver in demselben Tab auswerten. Der Wert muss false sein. Ist er true, fehlt in deinem MCP-Eintrag --autoConnect (bzw. --browserUrl bei einem eigenen Profil), und Chrome DevTools MCP hat ein eigenes Automatisierungs-Chrome gestartet. Bot-Prüfungen wie Cloudflare Turnstile bleiben dann endlos bei „Überprüfung“ hängen und zeigen nie eine Aufgabe, die du lösen könntest. Korrigiere den Eintrag, starte die Agentensitzung neu und wiederhole den Test. Verstecke das Flag nie mit Stealth-Flags oder Skripten.

Speichere in onboarding.json oder SESSION.md nur bestanden/nicht bestanden und nicht-sensible Notizen. Kopiere keine Cookies, Anmeldelinks oder Browser-Protokolle. Löse CAPTCHA/2FA selbst. Nach einem Timeout beim Absenden prüfst du die Plattform, bevor du es erneut versuchst. Bewegt sich das falsche Fenster, halte an und prüfe die Verbindung. Ohne diesen Test können diese Anweisungen deine konkrete Kombination aus Betriebssystem und Agent nicht bestätigen.

Zwei Worker und Aufräumen der Fenster

Der Laufplaner startet mit 10 Einreichungen und einem Browser-Worker. Ein zweiter Worker ist eine fortgeschrittene Option, die du selbst wählst, und erst, nachdem getrennt gesteuerte Browser getestet wurden. Er braucht dann eine eigene Plattformzuweisung, ein eigenes Chrome-Profil, einen eigenen Port und eine eigene MCP-Verbindung. Nutze zum Beispiel .browser/worker-1 auf 9222 und .browser/worker-2 auf 9223. Teste jeden einzeln. Kann der Host die Worker nicht auf getrennte Verbindungen leiten, bleib bei einem.

Gib jeder Einreichung ein eigenes Fenster. Sichere nach der Bestätigung Belege und Ergebnis und schließe dann nur dieses Fenster und die zugehörigen Anmelde- und Verifizierungs-Tabs. Lass persönliche Fenster, gemeinsame Postfächer, das Dashboard, ungespeicherte Formulare und Übergaben an Menschen offen. Kann MCP das Fenster nicht schließen, schließe die zugehörigen Tabs und halte fest, was der Besitzer noch aufräumen muss. Behalte das Profil; trennt das Schließen des letzten Fensters die MCP-Verbindung, verbinde neu. Die Onboarding-Anleitung erklärt den nächsten Schritt.