Como conectar o Playwright MCP ao Chrome pelo Remote Debugging

O Playwright não controla “o Chrome” por estar instalado na máquina. Ele controla um navegador que expôs uma sessão compatível com o Chrome DevTools Protocol (CDP) e cujo endpoint foi configurado no cliente de automação.

Essa distinção apareceu ao configurar o OpenCode para usar o servidor @playwright/mcp e listar as abas abertas no Chrome. A ferramenta tentou conectar a ws://localhost:9222, recebeu 403 Forbidden, e a primeira suspeita foi o navegador errado. O Edge estava usando a porta 9222; o Chrome estava aberto, mas não estava exposto nesse endpoint.

O objetivo não era escrever um teste E2E isolado. Era dar ao agente acesso controlado a uma sessão real do Chrome, sem navegar às cegas em uma janela do Edge e sem lançar uma cópia descartável do navegador. Isso muda o tipo de diagnóstico: a sessão, seus perfis e suas abas já existem, e o trabalho é conectar o cliente MCP à instância certa.

O que precisa estar alinhado

Há quatro peças independentes no fluxo:

• O navegador que está aberto: Chrome, Edge ou Chromium.
• O Remote Debugging, que cria uma superfície CDP para controle externo.
• A porta e o endpoint WebSocket oferecidos pelo navegador.
• O Playwright MCP, que precisa apontar para esse endpoint.

Uma extensão pode facilitar a autorização ou a integração com um agente, mas não transforma automaticamente uma sessão do Chrome em outra. Instalar a mesma extensão em dois navegadores também não faz o MCP alternar entre eles.

Diagnosticar a porta antes de mexer no Chrome

O primeiro passo foi verificar quem escutava em 9222, em vez de assumir que a porta pertencia ao Chrome:

lsof -nP -iTCP:9222

O processo principal era o Microsoft Edge. A linha de comando do Playwright MCP também mostrava o endpoint configurado:

--cdp-endpoint=ws://localhost:9222/devtools/browser/...

Isso explicava o comportamento: o Playwright estava tentando falar com o navegador associado à porta 9222, não com qualquer navegador aberto no desktop.

Por que o curl pode enganar

Em uma configuração CDP tradicional, estes endpoints costumam responder:

curl http://127.0.0.1:9222/json/version
curl http://127.0.0.1:9222/json/list

Mas o Remote Debugging iniciado pela integração do Chrome pode retornar 404 nesses caminhos e ainda assim estar funcional para o cliente esperado. O teste decisivo não é apenas a existência de uma resposta HTTP: é conectar pelo protocolo e conseguir listar os contextos ou abas.

Habilitar Remote Debugging no Chrome

No Chrome, abra:

chrome://inspect/#remote-debugging

Ative Allow remote debugging for this browser instance. O aviso é explícito: um cliente externo autorizado pode ler cookies, dados salvos e conteúdo dos sites, além de navegar para qualquer URL. Isso não é uma configuração de produtividade; é acesso de controle total ao navegador. A página também aponta para o Chrome DevTools MCP, que explica o modelo de conexão mantido pelo Chrome.

Depois de habilitar a opção, o Chrome exibiu:

Server running at: 127.0.0.1:59807

O detalhe que costuma confundir é a porta. O Chrome não precisou usar 9222; ele escolheu 59807. Essa porta pode mudar entre sessões, então não é seguro gravar um número fixo sem confirmar o valor exibido pelo navegador ou pelo mecanismo de integração.

Atualizar o endpoint do Playwright MCP

Enquanto o MCP continuava configurado para 9222, a tentativa falhou com:

connect ECONNREFUSED ::1:9222

Esse erro é diferente do 403 Forbidden inicial. O 403 indicava que havia um servidor na porta, mas ele rejeitava aquela conexão. O ECONNREFUSED indicava que não havia mais um servidor acessível no endereço resolvido para localhost:9222.

O MCP precisava ser apontado para a sessão do Chrome, usando a porta que o Chrome informou. A forma exata depende de como o MCP foi iniciado, mas o conceito é sempre este:

npx @playwright/mcp@latest \
  --cdp-endpoint=http://127.0.0.1:59807

Em uma integração baseada na extensão ou no Chrome DevTools MCP, o próprio botão Learn about connecting to Chrome DevTools MCP pode fornecer o endpoint e o procedimento de conexão. O ponto operacional é atualizar o cliente que estava preso ao Edge; instalar a extensão no Chrome, sozinho, não altera uma sessão MCP já iniciada. O OpenCode só descobre os servidores que foram declarados na sua configuração MCP: instalar o pacote @playwright/mcp não registra automaticamente o Chrome como uma ferramenta disponível ao agente.

Configurar o servidor no cliente MCP

Quando o cliente MCP usa servidores locais declarados em JSON, a configuração fica parecida com esta:

"playwright-chrome": {
  "command": [
    "/opt/homebrew/bin/npx",
    "-y",
    "@playwright/mcp@latest",
    "--cdp-endpoint=ws://localhost:59807/devtools/browser/<browser-session-id>",
    "--cdp-timeout=60000",
    "--output-dir=/tmp/playwright-mcp",
    "--output-mode=stdout"
  ],
  "enabled": false,
  "type": "local"
}

O valor de --cdp-endpoint é diferente do exemplo anterior com http://127.0.0.1:59807: aqui o cliente recebe o WebSocket completo, incluindo o identificador da sessão do navegador. Esse identificador não deve ser inventado nem reutilizado cegamente; copie o endpoint fornecido pelo Chrome DevTools MCP ou pelo mecanismo que iniciou a sessão. enabled: false também é deliberado: alguns clientes deixam o servidor cadastrado, mas exigem ativação explícita antes de iniciar um processo que terá controle total do navegador. Se o seu cliente não usa essa convenção, habilite o servidor pela configuração própria dele.

O caminho /opt/homebrew/bin/npx é específico de uma instalação do Homebrew em Apple Silicon. Em outra máquina, descubra o caminho com command -v npx e substitua apenas o executável. O diretório /tmp/playwright-mcp guarda a saída do servidor e não é o que conecta o navegador; a conexão é determinada pelo --cdp-endpoint. A documentação do Playwright MCP lista as opções do servidor e é a referência adequada quando a versão do pacote mudar.

Confirmar a conexão no navegador certo

Depois de alterar o endpoint do Playwright, a listagem de abas identificou o Chrome:

Extensões - Playwright Extension
chrome://extensions/?id=mmlmfjhmonkocbjadbfplnigmagldckm

Inspect with Chrome Developer Tools
chrome://inspect/#remote-debugging

YouTube
https://www.youtube.com/

Essa confirmação é mais útil que olhar apenas a porta. Ela prova simultaneamente que o cliente alcançou a sessão correta, que o navegador respondeu ao protocolo e que as abas disponíveis pertencem ao Chrome esperado.

O que a extensão faz, e o que ela não faz

O Edge tinha uma extensão chamada Playwright Extension, cuja descrição dizia que ela conecta o navegador a agentes de IA via Playwright MCP. Isso tornou a extensão uma suspeita razoável, mas a evidência posterior apontou para outra causa: a página edge://inspect/#remote-debugging informava que o Remote Debugging estava habilitado e o servidor estava escutando em 9222.

A separação correta é:

• O Remote Debugging abre a superfície CDP do navegador.
• O MCP usa essa superfície para controlar páginas.
• A extensão pode participar da autorização ou do fluxo específico do agente.
• A extensão não deve ser tratada como sinônimo de “o navegador está escutando em 9222”.

Para investigar uma extensão, desative-a, feche todas as janelas do navegador, abra o navegador novamente e confira quem escuta na porta. Se o processo principal continuar escutando, a origem está na configuração de inicialização, na política do navegador ou no mecanismo de Remote Debugging, não naquela extensão.

Segurança: o servidor deve ficar local

O Chrome mostrou 127.0.0.1, o que limita a escuta à máquina local. Ainda assim, qualquer processo com acesso ao endpoint pode controlar o navegador com os privilégios da sessão aberta. Isso inclui acessar sites autenticados e dados disponíveis no perfil.

Use Remote Debugging apenas com clientes confiáveis, não compartilhe o endpoint, não exponha a porta na rede e evite testar com um perfil que contenha dados que o agente não precisa. Uma sessão separada para automação reduz o impacto, mas não elimina o poder concedido ao cliente.

Fluxo consolidado

Para repetir o diagnóstico sem misturar Edge, Chrome e MCP:

1. Abra chrome://inspect/#remote-debugging no Chrome.
2. Ative o Remote Debugging e anote a porta exibida.
3. Confirme que o processo e o endpoint pertencem ao Chrome.
4. Atualize o --cdp-endpoint do Playwright MCP para essa sessão.
5. Reinicie o MCP se ele mantiver o endpoint anterior em memória.
6. Liste as abas e confirme uma URL chrome:// ou uma página que você reconheça.

Se aparecer 403, investigue a origem permitida e a compatibilidade do cliente com aquele endpoint. Se aparecer ECONNREFUSED, investigue host, porta, navegador ainda aberto e se o servidor foi desligado. Não trate os dois erros como variações da mesma falha.

A porta pertence à sessão, não ao navegador instalado

Uma consequência prática é que atualizar o Chrome, instalar a extensão ou abrir uma nova janela não garante que a porta antiga continue válida. O servidor pode ser encerrado quando a instância do navegador fecha, ou pode receber outra porta na próxima ativação. Por isso, scripts de desenvolvimento devem descobrir o endpoint no início da sessão ou consumir a configuração fornecida pelo MCP, em vez de assumir que 59807 será permanente. Também é possível ter Chrome e Edge abertos ao mesmo tempo, desde que cada um exponha uma porta diferente e cada cliente mantenha uma associação clara com seu navegador.

Checklist

• O Remote Debugging está habilitado no navegador que você quer controlar.
• A porta foi lida da sessão atual, não copiada de outro navegador.
• O MCP foi reiniciado ou reconfigurado com o endpoint correto.
• A listagem de abas confirma o navegador esperado.
• O endpoint está limitado a 127.0.0.1 e o cliente é confiável.
• O perfil usado não contém mais dados do que a automação precisa.

O detalhe que resolveu o problema não foi a extensão. Foi parar de pensar em “OpenCode conectado ao computador” e seguir a cadeia concreta: OpenCode, servidor MCP, navegador, CDP, porta e endpoint. Quando essa cadeia fica explícita, 403, 404 e ECONNREFUSED deixam de parecer mensagens aleatórias.