· Serhii Siryk · Development · 8 min de leitura
Automatizar Websites Autenticados com o Chrome DevTools MCP e o Claude Code
Digamos que está a desenvolver uma aplicação full-stack e algo falha quando um utilizador clica num botão — talvez o envio de um formulário, uma chamada de API, uma atualização de estado. Sabe que algo está errado, mas não onde. É um erro de JavaScript no frontend? Um pedido de rede falhado? Um 500 do backend? Normalmente, abriria o DevTools, reproduziria o problema, examinaria a consola e o separador de rede, e depois cruzaria tudo com os logs do servidor. Demora algum tempo.
Com o Chrome DevTools MCP — lançado pela Google em setembro de 2025 — pode entregar essa investigação ao Claude. Descreve o sintoma: «clicar no botão Submit na página de checkout não faz nada». O Claude navega até à página, abre a consola, clica no botão e observa o que acontece de verdade. Se existir uma exceção de JavaScript, rastreia-a até à origem. Se o botão disparar um pedido de rede que volta com um 422 ou um 500, o Claude captura o pedido e a resposta completos — cabeçalhos, payload, corpo do erro — e diz-lhe se o problema está no que o frontend enviou ou no que o backend devolveu.
Não fica pela identificação do erro. O Claude pode cruzar a resposta da API com o código que já conhece e dar-lhe um diagnóstico concreto: «o backend está a rejeitar o pedido porque o campo userId está em falta no payload — o frontend está a enviar user_id em vez disso». É o tipo de coisa que pode consumir uma hora da sua manhã se o fizer manualmente.
O mesmo fluxo de trabalho aplica-se a problemas mais subtis — um componente que é renderizado incorretamente para utilizadores autenticados, uma race condition que só aparece após uma sequência específica de ações, um pedido de rede que tecnicamente tem sucesso mas devolve dados obsoletos. O Claude torna-se algo próximo de um engenheiro júnior que pode sentar-se em frente ao browser e investigar de verdade — e não apenas ler código e adivinhar.
Há um senão na configuração padrão, no entanto: o Chrome é iniciado de cada vez com um perfil temporário e novo. Perfeito para páginas públicas, mas no momento em que a aplicação exige login, o browser não tem sessão. Este guia explica o passo extra que resolve isso.
A Chave: Um Perfil de Browser Separado
A solução é dar ao Chrome um perfil dedicado e isolado apenas para debugging — uma pasta separada no disco onde o Chrome guarda os seus próprios cookies, sessões e credenciais, completamente independente do seu browser principal. Pense nisto como uma segunda instalação do Chrome à qual só o Claude toca.
Isto tornou-se necessário a partir do Chrome 136, quando a Google reforçou a segurança em torno do remote debugging. A porta de remote debugging já não pode ser ativada no seu perfil padrão do Chrome — o Chrome simplesmente ignora a flag se tentar. A razão é legítima: uma porta de debugging aberta expõe o browser a qualquer processo em execução na sua máquina. Se fosse o seu perfil de todos os dias, uma aplicação maliciosa poderia ligar-se silenciosamente e drenar todos os cookies e tokens de sessão que tem.
O perfil isolado contorna isto de forma limpa. Aponta o Chrome para um diretório dedicado usando a flag --user-data-dir (já lá vamos), e o Chrome cria lá um perfil novo com as suas próprias chaves de encriptação. Inicie sessão no ambiente de staging, nas ferramentas internas, em tudo aquilo a que precisar que o Claude aceda — essas sessões persistem entre reinícios, e o seu perfil principal nunca entra em jogo.
Algumas regras de bom senso que vale a pena manter em mente: use este perfil apenas para serviços de desenvolvimento e testes, nunca abra banca ou email pessoal através dele, e feche o Chrome quando terminar o dia — a porta de debugging fecha com ele.
Configuração (Leva Cerca de 5 Minutos)
Passo 1: Lançar o Chrome com Remote Debugging Ativado
Feche primeiro quaisquer janelas do Chrome. Depois abra um terminal e execute:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.chrome-debug-profile"
A flag --remote-debugging-port=9222 abre um endpoint local de debugging na porta 9222. A flag --user-data-dir indica ao Chrome onde guardar os cookies, sessões e histórico deste perfil — o Chrome cria a pasta automaticamente no primeiro arranque.
Passo 2: Configurar o Claude Code
Adicione o servidor MCP Chrome DevTools através da CLI do Claude Code:
claude mcp add --transport stdio chrome-devtools \
-- npx -y chrome-devtools-mcp@latest \
--browserUrl=http://127.0.0.1:9222
O parâmetro --browserUrl indica ao servidor MCP para se ligar à sua instância do Chrome já em execução, em vez de lançar uma nova. O separador -- distingue as flags do Claude Code dos argumentos do servidor MCP. Sem ficheiros de configuração para editar, sem reinícios necessários.
Passo 3: Verificar que Funciona
Experimente um prompt de teste simples:
Navigate to https://google.com and capture a screenshot.
Se estiver tudo ligado corretamente, o Claude controla a janela do Chrome e devolve uma captura de ecrã. Pode ver o browser a atualizar em tempo real. Para um teste mais completo:
Analyze the performance of https://google.com
O Claude carrega a página, grava uma performance trace e reporta os resultados.
Facilitar o Lançamento
Escrever esse comando do Chrome todas as manhãs enfada depressa. Aqui ficam algumas alternativas melhores, da mais simples à mais polida:
Script de shell
Crie chrome-debug.sh:
#!/bin/bash
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.chrome-debug-profile" \
> /dev/null 2>&1 &
Torne-o executável com chmod +x chrome-debug.sh e execute-o com ./chrome-debug.sh. A parte > /dev/null 2>&1 & executa o Chrome silenciosamente em segundo plano.
Alias de shell
Adicione isto ao seu ~/.zshrc ou ~/.bashrc:
alias chrome:debug="/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir=\"$HOME/.chrome-debug-profile\" > /dev/null 2>&1 &"
Recarregue com source ~/.zshrc e depois basta escrever chrome:debug sempre que precisar. Muito menos fricção.
App no dock do macOS (a opção mais robusta)
Vale os cinco minutos extra. Em vez de um script ou alias, cria uma .app própria que fica no dock — visualmente distinta do Chrome habitual, impossível de confundir com ele. Sem terminal para lançar, e é um lembrete constante de que perfil está aberto.
Primeiro, crie a estrutura do app bundle:
mkdir -p /Applications/Chrome\ Debugger.app/Contents/MacOS
Depois crie o script executável dentro dele — o nome do ficheiro tem de corresponder ao nome da pasta de topo:
cd /Applications/Chrome\ Debugger.app/Contents/MacOS
touch Chrome\ Debugger
chmod +x Chrome\ Debugger
Abra o ficheiro no seu editor e adicione:
#!/usr/bin/env bash
exec /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.chrome-debug-profile"
Se estiver num Apple Silicon (M1/M2/M3), use esta versão em vez disso. O Chrome é distribuído como um universal binary com código x86_64 e arm64, e lançá-lo a partir do bash pode fazer com que escolha silenciosamente a arquitetura errada e corra sob Rosetta — sensivelmente mais lento. A flag arch -arm64 força o binário nativo:
#!/usr/bin/env bash
exec arch -arm64 "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
--remote-debugging-port=9222 \
--user-data-dir="$HOME/.chrome-debug-profile"
É tudo o que o macOS precisa para tratar isto como uma app lançável. Encontre-a em /Applications, arraste-a para o dock e está feito. Se quiser um ícone personalizado para a tornar ainda mais reconhecível, copie a imagem do ícone, clique com o botão direito na app → Get Info → clique na miniatura do ícone existente no canto superior esquerdo do painel de informação → cole. O macOS substitui-o imediatamente.
Resolução de Problemas
“Failed to connect to browser” — Certifique-se de que o Chrome está a correr com --remote-debugging-port=9222 antes de iniciar o Claude Code. Pode confirmar que a porta está ativa acedendo a http://127.0.0.1:9222 noutra janela do browser. Uma resposta JSON com a lista de targets de debugging significa que está a funcionar.
“Browser closes immediately” — Provavelmente está outra instância do Chrome em execução sem as flags de debugging. Termine todos os processos do Chrome e volte a lançar com o comando correto.
“Can’t find Chrome executable” — O Chrome normalmente reside em /Applications/Google Chrome.app/Contents/MacOS/Google Chrome. Se o instalou noutro local, atualize o caminho nos seus scripts.
Mais Uma Opção: Ligação Automática (Chrome 144+)
Se estiver no Chrome 144 ou mais recente (de momento em beta aquando da escrita), existe uma alternativa mais limpa à configuração manual de --remote-debugging-port. O servidor MCP Chrome DevTools suporta uma flag --autoConnect que lhe permite pedir uma ligação de debugging ao browser já em execução — sem flags de linha de comando no lado do Chrome.
Ativa-se uma única vez via chrome://inspect#remote-debugging, e o Chrome mostra um diálogo de permissão cada vez que um servidor MCP pede acesso. Vale a pena explorar se a abordagem de lançamento manual parecer demasiada fricção, embora o método --user-data-dir descrito acima seja mais fiável para ambientes sandboxed como o Claude Code.
Além do macOS e do Claude Code
Tudo o que aqui foi descrito aplica-se a outras plataformas e agentes. No Windows, o caminho do Chrome passa a ser "C:\Program Files\Google\Chrome\Application\chrome.exe". No Linux é normalmente /usr/bin/google-chrome. O comando de configuração do MCP é o mesmo independentemente do SO.
A mesma abordagem funciona com o Cursor, o GitHub Copilot e o Gemini CLI — qualquer cliente compatível com MCP que aceite um parâmetro --browserUrl se liga à sua instância do Chrome em execução da mesma forma.
A configuração leva cerca de cinco minutos. Depois disso, tem um browser persistente e autenticado que o Claude Code pode conduzir — o que acaba por ser surpreendentemente útil para tudo o que envolva sessões de login reais, ferramentas internas ou investigação em redes sociais.
