Conecta tu agente de código a tu Chrome

Configuración recomendada: para obtener los mejores resultados con LaunchRepo, te recomendamos encarecidamente usar siempre Claude Code CLI o Codex CLI en un terminal, en lugar de la app de escritorio de Claude o de Codex. Es nuestro flujo de trabajo recomendado, no una garantía de permisos distintos ni de una ejecución sin interrupciones.

Usa Chrome DevTools MCP a través de la depuración remota de Chrome, con una versión LTS actual de Node.js, npm y Google Chrome. El panel local guarda tus registros; tu agente controla Chrome. Empieza con un worker y mantén abierta su conexión MCP durante toda la ejecución. No uses transportes basados en extensiones del navegador ni otras integraciones alternativas de control del navegador.

Elige tu configuración

• Chrome 144+: el auto-connect funciona en Windows, macOS y Linux.
• macOS: revisa los permisos del Terminal.
• Auto-connect no disponible, o necesitas un worker aparte: usa un perfil dedicado para macOS, Windows o Linux.
• Antes de enviar: haz la prueba de conexión.

Comprueba node --version, npm --version y chrome://version. En Windows, usa Node/npm y Chrome nativos de Windows; WSL necesita una configuración de conexión propia.

Conecta el Chrome que ya usas

1. En Chrome 144+, abre chrome://inspect/#remote-debugging y activa la depuración remota. Si el control no aparece, usa uno de los perfiles dedicados permitidos que se describen más abajo.
2. Registra Chrome DevTools MCP en los ajustes MCP de tu agente. Este ejemplo JSON genérico es para macOS/Linux; tu agente puede usar otro formato de configuración:

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

En Windows, usa "command": "cmd" y estos argumentos:

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

3. Lanza una acción inofensiva en el navegador y aprueba el aviso de conexión de Chrome en la ventana prevista. Después haz la prueba de más abajo.

La primera llamada descarga el paquete. Cuando todo funcione, fija una versión probada. Consulta la configuración oficial y la configuración de clientes.

Perfil dedicado: elige tu sistema operativo

Ejecútalo desde tu espacio de trabajo privado, fuera de carpetas compartidas o sincronizadas. Deja el perfil ignorado por Git: contiene sesiones iniciadas. Inicia sesión tú mismo en las cuentas necesarias. Desde Chrome 136, estos flags de depuración exigen un perfil que no sea el predeterminado.

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

Deja abierto el terminal desde el que lo lanzaste. En los argumentos MCP, sustituye --autoConnect por --browserUrl=http://127.0.0.1:9222; nunca combines los dos. Mantén el puerto local y nunca lo expongas públicamente con un túnel. Comprueba el listener: lsof -nP -iTCP:9222 -sTCP:LISTEN en macOS, ss -ltnp 'sport = :9222' en Linux o Get-NetTCPConnection -State Listen -LocalPort 9222 | Select-Object LocalAddress, OwningProcess en Windows. Solo son aceptables direcciones de loopback. Si otro programa ocupa el puerto, elige uno libre y actualiza ambas configuraciones. Nunca mates navegadores ajenos ni borres bloqueos de perfiles activos.

Permisos de macOS

Revisa la app que lanza MCP: Terminal, iTerm o tu editor o app del agente. Si macOS deniega el acceso a archivos protegidos de Chrome:

1. Abre Ajustes del Sistema → Privacidad y seguridad → Acceso total al disco.
2. Añade esa app anfitriona real con +, autentícate y actívala.
3. Cierra la app por completo y vuelve a abrirla, reconecta y repite la prueba.

Es una comprobación de permisos, no un requisito general de CDP. Si la conexión funciona, no concedas más acceso del necesario. Una conexión solo CDP normalmente no necesita permisos de Accesibilidad, Automatización ni Grabación de pantalla. La aprobación de conexión de Chrome es independiente y puede volver a aparecer tras un reinicio.

Prueba la conexión

Pide a tu agente que abra https://example.com en una pestaña nueva, lea su título y su encabezado principal e identifique la pestaña. Mira esa ventana. Un proceso MCP en ejecución no demuestra nada por sí solo. Después inicia sesión en el directorio objetivo y confirma la identidad real en el destino; completar OAuth no demuestra por sí solo que haya sesión iniciada. Revisa tu buzón dentro de los permisos acordados.

A continuación, haz que el agente evalúe navigator.webdriver en esa misma pestaña. Tiene que ser false. Si es true, a tu entrada MCP le falta --autoConnect (o --browserUrl con un perfil dedicado) y Chrome DevTools MCP ha lanzado su propio Chrome de automatización. Las comprobaciones antibots como Cloudflare Turnstile se quedan entonces «verificando» para siempre y nunca muestran un desafío que puedas resolver. Corrige la entrada, reinicia la sesión del agente y repite la prueba. Nunca ocultes el flag con flags o scripts de sigilo.

Guarda solo apto/no apto y notas no sensibles en onboarding.json o SESSION.md. No copies cookies, enlaces de autenticación ni transcripciones del navegador. Los CAPTCHA y el 2FA los completas tú. Tras un timeout al enviar, revisa la plataforma antes de reintentar. Si se mueve la ventana equivocada, para y revisa la conexión. Sin esta prueba, estas instrucciones no pueden certificar tu combinación concreta de sistema operativo y agente.

Dos workers y limpieza de ventanas

El planificador de la ejecución empieza con 10 envíos y un worker de navegador. Un segundo worker es una opción avanzada que eliges tú, y solo después de haber probado navegadores controlados por separado. En ese caso necesita su propia asignación de plataformas, perfil de Chrome, puerto y conexión MCP. Por ejemplo, usa .browser/worker-1 en el 9222 y .browser/worker-2 en el 9223. Prueba cada uno por separado. Si el anfitrión no puede dirigir los workers a conexiones separadas, quédate con uno.

Dale a cada envío una ventana propia. Tras la confirmación, guarda su evidencia y su resultado y cierra solo esa ventana y sus pestañas propias de login o verificación. Deja abiertas las ventanas personales, los buzones compartidos, el panel, los formularios sin guardar y los relevos humanos. Si MCP no puede cerrar la ventana, cierra sus pestañas propias y registra la limpieza que le quede al propietario. Conserva el perfil; reconecta si al cerrar la última ventana se desconecta MCP. La guía del onboarding explica el siguiente paso.