Połącz agenta AI do kodowania ze swoim Chrome

Zalecana konfiguracja: Aby uzyskać najlepsze wyniki z LaunchRepo, zdecydowanie zalecamy, by zawsze używać Claude Code CLI lub Codex CLI w terminalu, a nie aplikacji desktopowej Claude lub Codex. To nasz zalecany sposób pracy, a nie gwarancja innych uprawnień ani nieprzerwanego działania.

Używaj Chrome DevTools MCP przez zdalne debugowanie Chrome z aktualną wersją Node.js LTS, npm i Google Chrome. Lokalny dashboard przechowuje twoje zapisy; przeglądarką Chrome steruje twój agent. Zacznij od jednego workera i nie zamykaj jego połączenia MCP przez cały czas trwania serii. Nie używaj transportów opartych na rozszerzeniach przeglądarki ani alternatywnych integracji do sterowania przeglądarką.

Wybierz konfigurację

• Chrome 144+: auto-connect działa w Windows, macOS i Linuksie.
• macOS: sprawdź uprawnienia Terminala.
• Auto-connect niedostępny albo potrzebny osobny worker: użyj osobnego profilu dla macOS, Windows lub Linuksa.
• Przed zgłoszeniem: wykonaj test połączenia.

Sprawdź node --version, npm --version i chrome://version. W Windows używaj natywnych dla Windows Node/npm i Chrome; WSL wymaga osobnej konfiguracji połączenia.

Połącz istniejący Chrome

1. W Chrome 144+ otwórz chrome://inspect/#remote-debugging i włącz zdalne debugowanie. Jeśli tej opcji brakuje, użyj dozwolonego osobnego profilu opisanego niżej.
2. Zarejestruj Chrome DevTools MCP w ustawieniach MCP swojego agenta. Ten ogólny przykład JSON dotyczy macOS/Linuksa; twój agent może używać innego formatu konfiguracji:

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

W Windows użyj "command": "cmd" i tych argumentów:

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

3. Wywołaj jakąś nieszkodliwą akcję w przeglądarce i we właściwym oknie zatwierdź monit Chrome o połączenie. Następnie wykonaj test opisany niżej.

Przy pierwszym wywołaniu pakiet zostanie pobrany. Po konfiguracji przypnij przetestowaną wersję. Zajrzyj do oficjalnej dokumentacji: konfiguracja i konfiguracja klientów.

Osobny profil: wybierz system operacyjny

Uruchamiaj z prywatnej przestrzeni roboczej, poza folderami współdzielonymi i synchronizowanymi. Profil musi być ignorowany przez Git, bo zawiera zalogowane sesje. Do wymaganych kont logujesz się samodzielnie. Chrome 136+ wymaga profilu innego niż domyślny, aby te flagi debugowania działały.

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

Nie zamykaj terminala, z którego uruchomiono Chrome. W argumentach MCP zastąp --autoConnect przez --browserUrl=http://127.0.0.1:9222; nigdy nie używaj obu naraz. Port ma pozostać lokalny — nigdy nie wystawiaj go publicznie przez tunel. Sprawdź, co nasłuchuje na porcie: lsof -nP -iTCP:9222 -sTCP:LISTEN w macOS, ss -ltnp 'sport = :9222' w Linuksie albo Get-NetTCPConnection -State Listen -LocalPort 9222 | Select-Object LocalAddress, OwningProcess w Windows. Dopuszczalne są wyłącznie adresy loopback. Jeśli port zajmuje inny program, wybierz wolny i zaktualizuj obie konfiguracje. Nigdy nie zabijaj niezwiązanych przeglądarek ani nie usuwaj blokad aktywnych profili.

Uprawnienia w macOS

Sprawdź aplikację, która uruchamia MCP: Terminal, iTerm albo twój edytor lub aplikację agenta. Jeśli macOS odmawia dostępu do chronionych plików Chrome:

1. Otwórz Ustawienia systemowe → Prywatność i ochrona → Pełny dostęp do dysku.
2. Dodaj tę właśnie aplikację hosta przyciskiem +, uwierzytelnij się i włącz ją.
3. Całkowicie zamknij aplikację i otwórz ją ponownie, połącz się jeszcze raz i powtórz test.

To kontrola uprawnień, a nie uniwersalny wymóg CDP. Jeśli połączenie działa, nie przyznawaj bez potrzeby szerszego dostępu. Samo połączenie przez CDP zwykle nie wymaga uprawnień Dostępność, Automatyzacja ani Nagrywanie ekranu. Zatwierdzenie połączenia w Chrome to osobna sprawa i po restarcie może być potrzebne ponownie.

Test połączenia

Poproś agenta, żeby otworzył https://example.com w nowej karcie, odczytał tytuł i główny nagłówek strony oraz wskazał, w której karcie pracuje. Obserwuj to okno. Sam działający proces MCP niczego nie dowodzi. Następnie zaloguj się do docelowego katalogu i sprawdź, na jakie konto faktycznie trafiasz — samo powodzenie OAuth nie dowodzi zalogowania. Sprawdź skrzynkę pocztową w granicach uzgodnionych uprawnień.

Następnie niech agent sprawdzi navigator.webdriver w tej samej karcie. Wartość musi wynosić false. Jeśli jest true, w konfiguracji MCP brakuje --autoConnect (lub --browserUrl przy osobnym profilu), a Chrome DevTools MCP uruchomił własnego Chrome do automatyzacji. Zabezpieczenia antybotowe, takie jak Cloudflare Turnstile, w nieskończoność „weryfikują” i nigdy nie pokazują wyzwania, które mógłbyś rozwiązać. Popraw konfigurację, uruchom ponownie sesję agenta i powtórz test. Nigdy nie ukrywaj tej flagi flagami ani skryptami typu stealth.

W onboarding.json lub SESSION.md zapisuj tylko wynik (zaliczony/niezaliczony) i niewrażliwe notatki. Nie kopiuj ciasteczek, linków uwierzytelniających ani transkryptów z przeglądarki. CAPTCHA i 2FA przechodzisz samodzielnie. Jeśli po kliknięciu Submit minie limit czasu, sprawdź stan na platformie, zanim spróbujesz ponownie. Jeśli porusza się niewłaściwe okno, zatrzymaj się i sprawdź połączenie. Bez tego testu te instrukcje nie są w stanie potwierdzić, że zadziałają w twojej konkretnej kombinacji systemu i agenta.

Dwa workery i zamykanie okien

Planer serii zaczyna od 10 zgłoszeń i maksymalnie 2 workerów. Każdy worker potrzebuje osobnego przydziału platform, własnego profilu Chrome, portu i połączenia MCP. Możesz na przykład użyć .browser/worker-1 na porcie 9222 i .browser/worker-2 na 9223. Przetestuj każdy z nich osobno. Jeśli host nie potrafi kierować workerów do osobnych połączeń, używaj jednego.

Każde zgłoszenie dostaje własne okno. Po potwierdzeniu zapisz dowody i wynik, a potem zamknij tylko to okno oraz należące do niego karty logowania i weryfikacji. Zostaw otwarte osobiste okna, współdzielone skrzynki, dashboard, niezapisane formularze i przekazania do człowieka. Jeśli MCP nie może zamknąć okna, zamknij należące do niego karty i zapisz, co jeszcze musi posprzątać właściciel. Zachowaj profil; jeśli zamknięcie ostatniego okna rozłączy MCP, połącz się ponownie. Przewodnik po onboardingu wyjaśnia kolejny krok.