Playwright CLI no Claude Code: Bots de Navegador Autonomos

A primeira vez que deixei o Claude Code dirigir um navegador real sem supervisao, estava assistindo um formulario de onboarding de 12 perguntas falhar em camera lenta. Pagina 1 funcionou. Pagina 2 funcionou. Pagina 3 — um textarea longo — travou. O agente pressionou Enter para avancar. Nada aconteceu. Pressionou de novo. Ainda nada. Entao fez algo que genuinamente nao esperava: tirou um screenshot, abriu o codigo-fonte da pagina, localizou o handler de keydown, percebeu que o textarea estava engolindo a tecla Enter em vez de propaga-la para o listener de submit do formulario, corrigiu o handler, fez redeploy, reexecutou o formulario, e me avisou quando todas as 12 perguntas foram submetidas sem problemas.

Todo aquele loop — testar, detectar, corrigir, retestar — levou cerca de onze minutos. Eu estava a um metro do meu teclado o tempo inteiro e contribui com zero teclas pressionadas.

A coisa que fez funcionar nao foi um prompt inteligente. Nao foi uma skill. Foi uma mudanca que eu tinha feito uma semana antes: trocar o Playwright MCP pelo Playwright CLI como as maos do Claude Code dentro do navegador. Essa unica mudanca cortou minha conta de tokens de automacao de navegador em aproximadamente 4x, tornou screenshots de debug saudaveis de revisar, e desbloqueou uma categoria de agente que eu realmente nao conseguia construir antes — loops autonomos de QA, scrapers que sobrevivem ao Google bloqueando-os, e bots atras de login que permanecem logados entre execucoes.

Este e o detalhamento completo. O que e o Playwright CLI, por que ele especificamente supera o Chrome DevTools MCP e o Playwright MCP para workloads do Claude Code, os tres padroes de producao que agora uso com ele, e as partes feias que ninguem menciona nos posts de lancamento.

Por Que o Playwright CLI Existe (E Por Que Nao E Apenas Mais Um MCP)

A Microsoft lancou o Playwright CLI no inicio de 2026 como um complemento deliberado — nao substituto — do Playwright MCP. O servidor MCP ainda existe. Ainda funciona. Mas a equipe percebeu algo que o resto de nos tambem estava percebendo: quando um agente de codigo como o Claude Code conversa com um navegador atraves de MCP, cada interacao de pagina faz um round-trip de uma arvore de acessibilidade completa de volta para a janela de contexto do modelo. Em uma pagina complexa, essa arvore tem 50.000 tokens. Por clique. Por scroll. Por tecla pressionada.

Multiplique isso por uma execucao de QA de 50 passos e voce entende por que meu dashboard da Anthropic estava gritando.

O Playwright CLI inverte o fluxo de dados. Em vez de transmitir a arvore de acessibilidade para o contexto do modelo, a CLI salva snapshots em disco como arquivos YAML compactos. O modelo le apenas a parte que pediu, quando pediu. Mesmo navegador. Mesma API Playwright por baixo. Relacionamento diferente entre o modelo e os dados.

Os numeros dos benchmarks publicos batem com o que vi nas minhas proprias contas:

Playwright MCP: ~1,5M tokens por execucao de automacao de navegador (pior caso, paginas completas, multiplos turnos)
Chrome DevTools MCP: ~330K tokens por execucao (melhor — snapshots delimitados, batching de chamada unica de execucao)
Playwright CLI: aproximadamente 4x menos tokens que o Playwright MCP para trabalho equivalente

Isso nao e uma otimizacao marginal. E a diferenca entre "posso rodar esse agente durante a noite" e "posso rodar esse agente por quarenta segundos antes do faturamento me mandar parar." Para pessoas que ja rastreiam custos de tokens agressivamente — e se voce nao rastreia, meu detalhamento de otimizacao de tokens do Claude Code vale a leitura antes de construir qualquer coisa disso — o Playwright CLI e a resposta para um problema que voce pode nao ter percebido que tinha.

Ha uma segunda razao pela qual importa e que ninguem comenta, e levei algumas sessoes para descobrir. Playwright CLI e uma CLI. Nao um daemon. Nao um servidor. Nao um protocolo. E um binario que voce chama com argumentos. O Claude Code e muito bom em chamar binarios com argumentos. Ele e menos bom em gerenciar uma conexao MCP de longa duracao, se recuperar de timeouts MCP, e analisar arvores de acessibilidade que nao pediu. O Playwright CLI joga a favor das forcas reais do Claude Code — bash, arquivos e chamadas de ferramentas pequenas e focadas.

Esse alinhamento e a coisa que o post do testcollab apontou como a verdadeira razao pela qual agentes de codigo o preferem. Eficiencia de tokens e a manchete. Adequacao da ferramenta e a substancia.

A Instalacao (E Por Que Pulo Metade da Configuracao Recomendada pela Microsoft)

Voce pode estar rodando o Playwright CLI dentro do Claude Code em cerca de noventa segundos. A instalacao e mais limpa que a do Playwright MCP, que costumava envolver copiar um snippet JSON no seu mcp.json e torcer para a string de versao nao divergir.

A versao da instalacao que eu realmente uso:

# Inicializar um projeto Playwright — cria package.json, tsconfig, testes de exemplo
npm init playwright@latest

# Instalar binarios dos navegadores (Chromium, Firefox, WebKit + dependencias)
npx playwright install --with-deps

# Verificar que a CLI funciona
npx playwright --version

Se voce quer disponivel globalmente em vez de por projeto:

npm install -g @playwright/cli@latest
playwright-cli install
playwright-cli install-browser

A Microsoft tambem oferece uma flag --skills (playwright-cli install --skills) que conecta o Playwright ao sistema de skills do Claude Code. Eu tentei. Funciona bem. Mas prefiro falar com a CLI diretamente atraves do bash porque da ao Claude superficies de erro mais claras — quando algo quebra na camada de skill, voce tem que debugar a skill e o comando subjacente. Quando algo quebra na camada de CLI, o stderr te diz exatamente o que aconteceu.

Uma vez instalado, a area de superficie que o Claude Code realmente usa e pequena:

npx playwright codegen <url> — gravar uma sessao, gerar um script de teste funcional
npx playwright test — rodar testes (headless por padrao, headed com --headed)
npx playwright test --debug — abrir o inspector, passar frame por frame
npx playwright show-trace trace.zip — revisar uma trace gravada depois

O Playwright CLI propriamente dito (o pacote @playwright/cli) adiciona um vocabulario diferente voltado para agentes de codigo — open, goto, click, type, fill, select, check, hover, drag, upload, snapshot, screenshot, close. O Claude tende a compor esses em scripts curtos em vez de chama-los um por um, o que e o instinto correto.

Agora a parte que importa: o que voce realmente constroi com isso.

Padrao 1: O Loop Autonomo de QA

Este e o caso de uso que me converteu. Eu tinha um formulario de onboarding com multiplas paginas — doze perguntas, seis paginas, ramificacao condicional na pagina quatro, uma tela de revisao, um fluxo de edicao-a-partir-da-revisao. Coisas padrao. Quebradas de forma nao-padrao.

A lista de bugs quando comecei a execucao:

A tecla Enter nao avancava o formulario nas paginas com textarea — apenas o botao explicito Proximo avancava
A pagina de revisao falhava em carregar cerca de 20% das vezes, retornando um componente em branco
O botao Editar na pagina de revisao ficava bloqueado por uma sobreposicao de modal obsoleta se voce tivesse dispensado um modal antes no fluxo

Eu sabia do primeiro. Os outros dois descobri porque deixei o agente rodar.

O script que o Claude Code escreveu para si mesmo, levemente limpo:

import { test, expect } from '@playwright/test';

test('full onboarding flow — 12 questions, 6 pages', async ({ page }) => {
  await page.goto('http://localhost:3000/onboarding');

  for (let pageNum = 1; pageNum <= 6; pageNum++) {
    await page.screenshot({
      path: `screenshots/onboarding-page-${pageNum}.png`,
      fullPage: true,
    });

    // Fill whatever inputs exist on this page
    const inputs = await page.locator('input, textarea, select').all();
    for (const input of inputs) {
      const type = await input.getAttribute('type');
      if (type === 'email') await input.fill('[email protected]');
      else if (type === 'tel') await input.fill('555-0100');
      else await input.fill('automated test response');
    }

    // Advance — explicit button click, not Enter
    await page.getByRole('button', { name: /next|continue|review/i }).click();
    await page.waitForLoadState('networkidle');
  }

  await expect(page.getByText(/thank you|submitted/i)).toBeVisible({
    timeout: 10_000,
  });
});

A instrucao do Claude Code que o conduziu foram quatro frases: "Rode o teste. Se falhar, tire screenshot do ponto de falha, leia o codigo-fonte do componente que falhou, proponha uma correcao, aplique-a, reinicie o servidor de desenvolvimento e reexecute. Repita ate o teste passar tres vezes seguidas. Nao me pergunte sobre nada abaixo de P0."

O agente rodou o teste. Falhou na pagina 3 — tecla Enter, o bug que eu conhecia. Abriu o componente do textarea, encontrou o handler onKeyDown que chamava event.preventDefault() incondicionalmente, restringiu para so prevenir Enter quando Shift estava pressionado (para que a entrada multi-linha ainda funcionasse), salvou, reiniciou o dev, reexecutou. O teste passou a pagina 3, falhou na pagina 4 — a pagina de revisao em branco. O agente suspeitou de uma corrida entre o carregador de rota e o hook de estado do formulario, adicionou um estado de carregamento, tentou novamente. Passou. Falhou na colisao do modal no Editar-a-partir-da-revisao. Escreveu um pequeno effect que limpava sobreposicoes de modal na mudanca de rota. Passou tres vezes seguidas. Parou. Escreveu um resumo em qa-run.md.

Onze minutos. Tres bugs reais encontrados e corrigidos. Um humano supervisionando do outro lado da sala.

O padrao, destilado:

Testar — Playwright CLI roda o script
Detectar — Na falha, screenshot + ler codigo-fonte + formar uma hipotese
Corrigir — Aplicar o patch, reiniciar o que precisa reiniciar
Retestar — Repetir ate verde N vezes seguidas, nao apenas uma

O requisito de "N vezes seguidas" esta fazendo muito trabalho. Um teste instavel que passa uma vez nao esta corrigido. Tres passagens consecutivas e o menor tamanho de amostra onde voce pode dizer com credibilidade que a correcao se manteve.

Isso e genuinamente o mais proximo que vi o Claude Code chegar de se comportar como um engenheiro de QA junior que realmente finaliza o ticket. Se voce quer ver como esse tipo de loop se compoe em um workflow de engenharia mais amplo, o post sobre a stack de skills do Claude Code detalha as camadas acima desta — Superpowers, Skill Creator, o resto. O Playwright CLI sao os olhos e as maos. Aquelas skills sao o cerebro.

Padrao 2: Web Scraping Adaptativo (Quando o Google Decide Que Enjoou de Voce)

Trabalho diferente, licao diferente. Um amigo que administra um pequeno servico de marketing odontologico perguntou se eu podia puxar informacoes de contato — nome, endereco, telefone — de cada dentista em alguns CEPs especificos da California. Tempo de pesquisa manual por CEP: quatro a seis horas. Informacao publica, apenas tediosa de coletar.

O primeiro script que o Claude escreveu foi o obvio: pesquisar no Google por dentist near 94110, analisar a SERP, visitar cada resultado, extrair o numero de telefone da pagina de contato. Funcionou. Por cerca de trinta pesquisas. Entao o Google serviu um CAPTCHA, depois um bloqueio suave, depois um limite de taxa rígido.

A correcao foi a parte interessante. Sem eu pedir, o Claude adicionou tres comportamentos:

import { chromium } from 'playwright';

async function adaptiveSearch(query: string) {
  const browser = await chromium.launch({ headless: true });
  const context = await browser.newContext({
    userAgent: 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ' +
               'AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36',
  });
  const page = await context.newPage();

  // 1. Try Google first
  await page.goto(`https://www.google.com/search?q=${encodeURIComponent(query)}`);

  // 2. Detect blocking — captcha, "unusual traffic" page, empty results
  const blocked = await page.locator('text=/unusual traffic|captcha|are you a robot/i').count();
  if (blocked > 0) {
    console.log('Google blocked — switching to DuckDuckGo');
    await page.goto(`https://duckduckgo.com/?q=${encodeURIComponent(query)}`);
  }

  // 3. Random jitter between requests so the cadence doesn't look automated
  await page.waitForTimeout(2000 + Math.random() * 3000);

  return page;
}

Esse fallback sozinho — Google para DuckDuckGo quando bloqueado — levou o script de "morre apos 30 pesquisas" para "rodou por seis horas sem supervisao." O DuckDuckGo nao tem a infraestrutura anti-bot do Google, o layout da SERP e mais simples de analisar, e para uma pesquisa como "dentist 94110" a qualidade dos resultados e essencialmente equivalente.

A segunda adaptacao foi mais sutil. O numero de telefone era visivel na SERP para cerca de 70% dos listagens de dentistas — o Google puxa dos dados estruturados e mostra inline. O scraper ingenuoalegremente pegaria aquele numero visivel e seguiria em frente. O problema: aquele numero as vezes e um numero de rastreamento de marketing, nao a linha real do dentista.

Entao o Claude atualizou a logica: mesmo quando um telefone esta visivel na SERP, clicar no resultado e ir para a pagina de contato do dentista para pegar o numero de la. Mais lento por registro. Maior precisao. O tipo de decisao que um humano cuidadoso tomaria e uma automacao desleixada pularia.

O script completo de coleta rodou por menos de tres horas, encontrou ~430 dentistas da California em cinco CEPs, e produziu um CSV com nome, endereco, telefone, site e (quando disponivel) horario de funcionamento. Custo em tokens de API, com o Playwright CLI gerenciando o navegador em vez do MCP: cerca de $4,20.

Duas regras praticas que agora aplico a todo trabalho de scraping:

Sempre tenha um mecanismo de busca de fallback. O Google e a melhor fonte ate ser a pior fonte. Seu script deve detectar a transicao sem voce ficar de baba.
Desconfie da SERP para qualquer dado que tenha valor comercial. Numeros de telefone, precos, horarios — clique e verifique. A latencia extra e mais barata que uma lista de contatos cheia de becos sem saida.

Se voce esta construindo algo mais complexo que isso, meu post sobre WebMCP para agentes Chrome de IA cobre a alternativa quando voce precisa de funcionalidades especificas do protocolo Chrome que o Playwright nao expoe.

Este e o padrao que realmente mudou o que eu acho que o Claude Code pode fazer.

Fazer scraping de paginas publicas e facil. Qualquer coisa atras de um login e a verdadeira fronteira — e a maior parte do trabalho interessante acontece atras de um login. Canais do Slack. Plataformas escolares. Dashboards internos. Produtos SaaS pelos quais voce paga. O desafio nao e fazer login uma vez. E permanecer logado, entre execucoes, entre dias, entre reinicializacoes do navegador, sem voce redigitar credenciais toda vez.

O contexto persistente do Playwright e a resposta, e a maioria dos tutoriais erra porque confunde storageState com launchPersistentContext. Eles nao sao a mesma coisa.

storageState e um snapshot de cookies + localStorage, gravado em um arquivo JSON. Bom para execucoes headless de CI onde voce faz login uma vez, salva o estado e reutiliza em centenas de execucoes de teste.

// Save after a successful login
await page.context().storageState({ path: 'auth.json' });

// Reuse in later runs
const context = await browser.newContext({ storageState: 'auth.json' });

launchPersistentContext e um perfil real de navegador em disco. Cookies, cache, localStorage, IndexedDB, registros de service worker, tudo. Isso e o que voce quer quando precisa se comportar como um usuario real logado entre sessoes — nao apenas um executor de testes logado.

import { chromium } from 'playwright';

const userDataDir = '/Users/mejba/.playwright-profiles/school-platform';
const context = await chromium.launchPersistentContext(userDataDir, {
  headless: false, // first run only — log in by hand
  viewport: { width: 1440, height: 900 },
});

const page = context.pages()[0] ?? await context.newPage();
await page.goto('https://school.example.com');
// Log in manually, complete 2FA, dismiss any onboarding modals
// Then close the browser. The profile is now persisted.

O padrao de passagem de bastao e a parte que levei algumas noites para acertar. Primeira execucao: headed, login manual, 2FA manual, tudo-que-o-bot-nao-consegue-fazer manual. Execucoes subsequentes: mesmo userDataDir, mas headless, e voce ja esta autenticado. Os cookies, os tokens de sessao, as coisas de fingerprint de dispositivo — tudo vive em disco naquele diretorio de perfil.

Para uma automacao de plataforma escolar que construi — um script diario que puxa posts marcados como "vitorias" por colegas, classifica por recencia, e curte os cinco primeiros — a execucao se parece com isto:

import { chromium } from 'playwright';

(async () => {
  const context = await chromium.launchPersistentContext(
    '/Users/mejba/.playwright-profiles/school-platform',
    { headless: true }
  );
  const page = await context.newPage();

  await page.goto('https://school.example.com/channels/wins');

  // Filter by newest — the platform's UI tab
  await page.getByRole('tab', { name: 'Newest' }).click();
  await page.waitForLoadState('networkidle');

  // Scroll until we have 30 posts loaded
  for (let i = 0; i < 5; i++) {
    await page.mouse.wheel(0, 2000);
    await page.waitForTimeout(800);
  }

  // Like the top 5 — but throttled, because the platform crashed
  // when I tried to like 5 in 2 seconds during my first run
  const likeButtons = await page
    .locator('[data-testid="like-button"]')
    .filter({ hasNotText: 'Liked' })
    .all();

  for (const button of likeButtons.slice(0, 5)) {
    await button.click();
    await page.waitForTimeout(1500); // throttle
  }

  await context.close();
})();

O throttle no loop esta la por causa de um bug real que causei. Minha primeira versao do script clicou todas as cinco curtidas dentro de um Promise.all. O frontend da plataforma nao e construido para lidar com cinco mutacoes de curtida concorrentes da mesma sessao e quebrou a arvore React no meio da renderizacao. O Claude descobriu isso lendo o screenshot do estado quebrado, encontrando o overlay de erro do React, lendo o stack trace, e decidindo que a correcao era um delay em vez de logica de retry.

Aquele loop iterativo — quebrar, screenshot, ler o erro, formular hipotese, corrigir, reexecutar — e exatamente o mesmo loop do Padrao 1. Dominio diferente, forma identica.

Conectando a Um Navegador Ja Em Execucao (CDP)

Ha uma terceira opcao para o problema do "logado" que vale a pena conhecer mesmo que voce nao use com frequencia: conectar o Playwright a uma instancia do Chrome que voce mesmo iniciou.

Lance o Chrome com a porta do debugger aberta:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-debug-profile

Entao faca o Claude Code se conectar a ele a partir de um script Playwright:

import { chromium } from 'playwright';

const browser = await chromium.connectOverCDP('http://localhost:9222');
const context = browser.contexts()[0]; // attach to the existing default context
const page = context.pages()[0] ?? await context.newPage();

Quando isso e util: voce navegou manualmente por um fluxo de autenticacao complexo de multiplos passos (redirecionamentos SSO, prompts de chave de hardware, captchas) e quer que o agente assuma de onde voce parou. Modo headed, navegador real, cookies reais, sem copia de perfil. A limitacao: CDP so funciona para navegadores baseados em Chromium — nao Firefox ou WebKit.

Uso isso talvez uma em cada vinte automacoes. Mas nas vezes que uso, nada mais resolve o mesmo problema.

Headed vs Headless — Uma Regra, Nao Uma Preferencia

O padrao em CI e headless. O padrao durante desenvolvimento deveria ser headed para a primeira execucao de qualquer nova automacao, depois headless quando estiver estavel.

A razao e assimetria de debug. Quando uma execucao headless falha, voce tem um screenshot, uma trace e sua imaginacao. Quando uma execucao headed falha, voce pode ver o navegador real cometendo o erro real em tempo real. A diferenca entre essas duas experiencias de debug e a diferenca entre corrigir um bug em vinte minutos e corrigi-lo em tres horas.

A flag e apenas --headed:

npx playwright test --headed --debug

--debug adiciona o inspector — pausa em cada acao, avanca passo a passo, modifica seletores ao vivo. Use uma vez. Voce nunca mais vai voltar a debugar Playwright com print.

A excecao: sempre que o agente esta rodando sem supervisao, deve ser headless. Execucoes headed precisam de um servidor de display, sao encerradas quando sua sessao termina, e adicionam overhead real. A troca de uma linha e o que voce quer — headed durante a construcao, headless durante a execucao.

Para Que Nao Usarei o Playwright CLI

Esta e a parte que a maioria dos posts pula. Tres coisas que tentei e voltei atras.

Debug pesado de rede/performance. O Playwright CLI pode capturar logs de rede e traces, mas para debug serio — comparar tempos de waterfall, perfilar hot paths de JavaScript, inspecionar eventos em nivel de CDP — o Chrome DevTools MCP e genuinamente melhor. A ferramenta execute agrupa acoes em uma unica chamada e os dados nativos de CDP sao mais ricos. Mantenho ambos instalados e uso o DevTools MCP quando a pergunta e "por que essa pagina esta lenta" em vez de "essa pagina funcionou."

Qualquer coisa dentro de iframes de uma origem diferente. O Playwright lida com iframes cross-origin, mas a API fica feia rapido — chains de frameLocator, posicionamento cuidadoso de waitFor, e uma suspeita permanente de que os seletores nao vao sobreviver ao proximo deploy. Para widgets de anuncios, fluxos embarcados de Stripe/Plaid, ou popups de login social, eu ou intercepto na camada de rede ou simplesmente nao automatizo essa etapa. O custo-beneficio nao esta la.

Fluxos de confirmacao por email. O Playwright clicara alegremente no link do email se voce der o link a ele. A parte dificil e conseguir o link. APIs de caixa de correio (Mailtrap, Mailosaur) resolvem isso; o Playwright nao. Tentar fazer scraping do Gmail para o email de verificacao e um caminho para a dor.

O resumo honesto: Playwright CLI e o padrao correto para automacao de navegador dentro do Claude Code em 2026. Nao e a ferramenta certa para trabalho de performance, fluxos exoticos de embed, ou encanamento de email. Saber onde estao os limites te poupa de aprende-los as 2 da manha.

Uma automacao de navegador que so roda quando voce lembra de rodar e uma demo. Automacoes de navegador de producao rodam em um cronograma.

Tres opcoes, cada uma adequada a uma realidade diferente:

Modal — Python serverless com suporte de primeira classe ao Playwright. Voce define uma funcao com @modal.function(schedule=modal.Cron("0 9 * * *")) e o Modal cuida do container, dos binarios do navegador, do isolamento de execucao, dos logs. Meu bot diario de resumo de noticias roda aqui. Cerca de $0,40 por dia em computacao.

Trigger.dev — TypeScript-nativo, o ecossistema JS parece mais proximo se seus scripts Playwright ja sao TS. A primitiva browser-task deles e construida especificamente para workloads Playwright.

Cron de desktop + headless — para automacoes pessoais no seu proprio laptop. Funciona. Quebra no momento em que seu laptop dorme, o wifi cai, ou o navegador atualiza. Nao use para nada que importa.

Comecei tudo com cron de desktop porque era gratis. Migrei para o Modal depois da terceira execucao perdida durante um voo. Conta mensal total entre quatro bots agendados: menos de $25. Vale a pena.

A Camada de Agente Por Cima

Uma vez que o Playwright CLI esta conectado e seus primeiros tres padroes funcionam, a tentacao e continuar construindo scripts maiores. Nao faca isso. O proximo passo e construir agentes que chamam os scripts.

Um agente de resumo diario de noticias que:

Acorda as 8 da manha
Puxa manchetes de tres feeds RSS via HTTP simples (sem navegador necessario)
Pede ao Claude para resumir e classificar
Chama um script Playwright CLI para postar o resumo em um canal do Slack
Monitora o canal por respostas nos proximos trinta minutos via sessao persistente
Pede ao Claude para rascunhar respostas para qualquer coisa que precise de uma
Chama outro script Playwright para postar as respostas

Cada peca e pequena. As partes de navegador sao minusculas — um clique, uma digitacao, um screenshot, uma saida. O raciocinio do agente vive fora do navegador. O navegador e apenas maos.

Essa separacao e todo o ponto de preferir CLI sobre MCP para esses workflows. A camada de navegador deveria ser barata, rapida e simples. A camada de raciocinio e onde os tokens devem ir. Quando a camada de navegador tambem esta consumindo tokens — que e o que o Playwright MCP faz, em cada pagina — a matematica para de funcionar em qualquer escala nao-trivial.

O enquadramento mais proximo que posso te dar: Playwright CLI esta para automacao de navegador assim como bash esta para automacao de filesystem. Pequeno, afiado, scriptavel. Facil de compor em algo maior. Esquecivel da forma que boa infraestrutura deve ser.

Perguntas Frequentes

O Playwright CLI e um substituto do Playwright MCP?

Nao — o Playwright CLI e uma ferramenta complementar, nao um substituto. Use CLI quando um agente de codigo como o Claude Code esta dirigindo o navegador; use MCP quando um workflow de agente autonomo precisa do protocolo padrao MCP. A Microsoft mantem ambos deliberadamente.

Quanto o Playwright CLI realmente economiza em tokens vs Playwright MCP?

Benchmarks publicos e minhas proprias execucoes mostram aproximadamente 4x menos tokens por sessao com Playwright CLI vs Playwright MCP. A economia vem do CLI salvar snapshots em disco como YAML compacto em vez de transmitir arvores de acessibilidade completas para o contexto do modelo em cada interacao.

O Playwright CLI pode me manter logado entre execucoes?

Sim — use chromium.launchPersistentContext(userDataDir, { headless: false }) para o primeiro login manual, depois rode automacoes subsequentes com o mesmo userDataDir em modo headless. Cookies, localStorage e tokens de sessao todos persistem em disco.

Quando devo usar o Chrome DevTools MCP em vez disso?

Use o Chrome DevTools MCP quando a tarefa e profiling de performance, analise de waterfall de rede, ou qualquer debug profundo em nivel de CDP. Tambem e mais eficiente em tokens que o Playwright MCP para esses workloads especificos. Para automacao direta e loops de QA, o Playwright CLI ganha.

O Claude Code consegue escrever scripts Playwright do zero?

Sim — e e confiavel. Use npx playwright codegen <url> para gravar uma sessao inicial se quiser dar uma base ao script, depois deixe o Claude refinar. Para a maioria das automacoes eu descrevo o objetivo em 2-3 frases e o script funcional esta escrito antes de eu terminar meu cafe.

Os Onze Minutos Que Mudaram Como Eu Construo

Voltando ao formulario de onboarding. Onze minutos, tres bugs reais encontrados e corrigidos, zero teclas pressionadas por mim. A coisa em que fico pensando nao e a velocidade — e que o loop se fechou sozinho. O agente nao escreveu codigo e parou. Ele escreveu codigo, rodou o teste, viu a falha, rastreou a causa, aplicou a correcao e reexecutou o teste ate o resultado corresponder ao objetivo.

Esse loop fechado e o que faz a automacao de navegador finalmente parecer infraestrutura em vez de teatro. O Playwright CLI nao inventou o loop. Ele o tornou barato o suficiente para rodar.

Escolha um dos tres padroes deste post hoje a noite. O loop de QA e o mais facil para comecar — aponte o Claude para qualquer app com formularios pesados que voce mantém, de a instrucao de quatro frases de antes, saia por dez minutos. Volte. Veja o que ele encontrou. A primeira vez que o loop pegar um bug real que voce nao sabia, voce vai entender por que mudei como eu construo.

Vamos Trabalhar Juntos

Quer construir sistemas de IA, automatizar workflows ou escalar sua infraestrutura tech? Adoraria ajudar.

Fiverr (builds customizados e integracoes): fiverr.com/s/EgxYmWD
Portfolio: mejba.me
Ramlit Limited (solucoes enterprise): ramlit.com
ColorPark (design e branding): colorpark.io
xCyberSecurity (servicos de seguranca): xcybersecurity.io

Playwright CLI no Claude Code: Bots de Navegador Autonomos