Playwright CLI in Claude Code: Autonome Browser-Bots

Das erste Mal, als ich Claude Code einen echten Browser unbeaufsichtigt steuern ließ, beobachtete ich, wie ein 12-Fragen-Onboarding-Formular in Zeitlupe scheiterte. Seite 1 funktionierte. Seite 2 funktionierte. Seite 3 — ein langes Textarea-Feld — fror ein. Der Agent drückte Enter zum Weiterblättern. Nichts passierte. Drückte es erneut. Immer noch nichts. Dann tat er etwas, das ich wirklich nicht erwartet hatte: Er machte einen Screenshot, öffnete den Seitenquellcode, fand den Keydown-Handler, bemerkte, dass das Textarea die Enter-Taste verschluckte, anstatt sie an den Submit-Listener des Formulars weiterzuleiten, patchte den Handler, deployete neu, führte das Formular erneut aus und benachrichtigte mich, als alle 12 Fragen sauber abgeschickt waren.

Diese ganze Schleife — testen, erkennen, beheben, erneut testen — dauerte etwa elf Minuten. Ich war die gesamte Zeit knapp einen Meter von meiner Tastatur entfernt und trug null Tastatureingaben bei.

Was es zum Funktionieren brachte, war kein cleverer Prompt. Es war kein Skill. Es war ein Schalter, den ich eine Woche zuvor umgelegt hatte: den Wechsel von Playwright MCP zu Playwright CLI als Claude Codes Hände im Browser. Diese einzelne Änderung reduzierte meine Browser-Automatisierungs-Token-Rechnung um ungefähr das Vierfache, machte Debug-Screenshots vernünftig überprüfbar und ermöglichte eine Kategorie von Agenten, die ich vorher nicht wirklich hatte bauen können — autonome QA-Schleifen, Scraper, die Googles Blockierung überstehen, und Login-geschützte Bots, die über mehrere Durchläufe eingeloggt bleiben.

Dies ist die vollständige Aufschlüsselung. Was Playwright CLI ist, warum es speziell Chrome DevTools MCP und Playwright MCP für Claude Code-Workloads übertrifft, die drei Produktionsmuster, die ich jetzt damit verwende, und die hässlichen Stellen, die niemand in den Launch-Posts erwähnt.

Warum Playwright CLI existiert (und warum es nicht einfach ein weiteres MCP ist)

Microsoft hat Playwright CLI Anfang 2026 als bewusstes Begleitwerkzeug — nicht als Ersatz — für Playwright MCP veröffentlicht. Der MCP-Server existiert weiterhin. Er funktioniert weiterhin. Aber das Team bemerkte etwas, das der Rest von uns ebenfalls bemerkte: Wenn ein Coding-Agent wie Claude Code über MCP mit einem Browser kommuniziert, wird bei jeder einzelnen Seiteninteraktion ein vollständiger Accessibility-Tree zurück in das Kontextfenster des Modells geschickt. Bei einer komplexen Seite sind das 50.000 Tokens. Pro Klick. Pro Scrollen. Pro Tastatureingabe.

Multiplizieren Sie das mit einem 50-Schritt-QA-Durchlauf und Sie verstehen, warum mein Anthropic-Dashboard Alarm schlug.

Playwright CLI dreht den Datenfluss um. Anstatt den Accessibility-Tree in den Modellkontext zu streamen, speichert die CLI Snapshots auf die Festplatte als kompakte YAML-Dateien. Das Modell liest nur den Teil, den es angefordert hat, wann es ihn angefordert hat. Derselbe Browser. Dieselbe Playwright-API darunter. Eine andere Beziehung zwischen dem Modell und den Daten.

Die Zahlen aus den öffentlichen Benchmarks decken sich mit dem, was ich auf meinen eigenen Rechnungen gesehen habe:

Playwright MCP: ~1,5 Millionen Tokens pro Browser-Automatisierungsdurchlauf (Worst Case, volle Seiten, mehrere Turns)
Chrome DevTools MCP: ~330.000 Tokens pro Durchlauf (besser — scoped Snapshots, einzelne Execute-Call-Bündelung)
Playwright CLI: ungefähr 4x weniger Tokens als Playwright MCP für gleichwertige Arbeit

Das ist keine marginale Optimierung. Das ist der Unterschied zwischen „Ich kann diesen Agenten über Nacht laufen lassen" und „Ich kann diesen Agenten vierzig Sekunden laufen lassen, bevor die Abrechnung mir sagt, ich soll aufhören." Für Leute, die Token-Kosten bereits aggressiv verfolgen — und wenn Sie das nicht tun, ist meine Claude Code Token-Optimierungs-Aufschlüsselung lesenswert, bevor Sie irgendetwas davon bauen — ist Playwright CLI die Antwort auf ein Problem, von dem Sie möglicherweise nicht wussten, dass Sie es hatten.

Es gibt einen zweiten Grund, warum es wichtig ist, über den niemand spricht, und ich brauchte ein paar Sessions, um es herauszufinden. Playwright CLI ist eine CLI. Kein Daemon. Kein Server. Kein Protokoll. Es ist eine Binärdatei, die man mit Argumenten aufruft. Claude Code ist sehr gut darin, Binärdateien mit Argumenten aufzurufen. Es ist weniger gut darin, eine langlebige MCP-Verbindung zu verwalten, sich von MCP-Timeouts zu erholen und Accessibility-Trees zu parsen, nach denen es nicht gefragt hat. Playwright CLI spielt auf Claude Codes tatsächliche Stärken an — Bash, Dateien und kleine, fokussierte Tool-Aufrufe.

Diese Passung ist das, was der testcollab-Beitrag als den eigentlichen Grund herausstellte, warum Coding-Agenten es bevorzugen. Token-Effizienz ist die Schlagzeile. Tool-Passung ist die Substanz.

Die Installation (und warum ich die Hälfte von Microsofts empfohlenem Setup überspringe)

Sie können Playwright CLI innerhalb von etwa neunzig Sekunden in Claude Code zum Laufen bringen. Die Installation ist sauberer als bei Playwright MCP, bei dem man früher einen JSON-Schnipsel in die mcp.json kopieren und hoffen musste, dass der Versions-String nicht abdriftete.

Die Version der Installation, die ich tatsächlich verwende:

# Initialize a Playwright project — creates package.json, tsconfig, example tests
npm init playwright@latest

# Install browser binaries (Chromium, Firefox, WebKit + dependencies)
npx playwright install --with-deps

# Verify the CLI works
npx playwright --version

Wenn Sie es überall verfügbar haben möchten statt pro Projekt:

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

Microsoft liefert auch ein --skills-Flag (playwright-cli install --skills), das Playwright in Claude Codes Skill-System einbindet. Ich habe es ausprobiert. Es funktioniert gut. Aber ich spreche lieber direkt über Bash mit der CLI, weil es Claude klarere Fehleroberflächen gibt — wenn etwas auf der Skill-Ebene bricht, müssen Sie den Skill und den zugrunde liegenden Befehl debuggen. Wenn etwas auf der CLI-Ebene bricht, sagt Ihnen stderr genau, was passiert ist.

Sobald es installiert ist, ist die Oberfläche, die Claude Code tatsächlich nutzt, klein:

npx playwright codegen <url> — eine Session aufzeichnen, ein funktionierendes Testskript ausgeben
npx playwright test — Tests ausführen (standardmäßig headless, mit --headed sichtbar)
npx playwright test --debug — den Inspector öffnen, Frame für Frame durchgehen
npx playwright show-trace trace.zip — einen aufgezeichneten Trace nachträglich überprüfen

Die eigentliche Playwright CLI (das @playwright/cli-Paket) legt ein anderes Vokabular darüber, das auf Coding-Agenten ausgerichtet ist — open, goto, click, type, fill, select, check, hover, drag, upload, snapshot, screenshot, close. Claude neigt dazu, diese zu kurzen Skripten zusammenzufügen, anstatt sie einzeln aufzurufen, was der richtige Instinkt ist.

Nun der Teil, der zählt: was man tatsächlich damit baut.

Muster 1: Die autonome QA-Schleife

Das ist der Anwendungsfall, der mich überzeugt hat. Ich hatte ein mehrseitiges Onboarding-Formular — zwölf Fragen, sechs Seiten, bedingte Verzweigung auf Seite vier, eine Überprüfungsseite, einen Bearbeiten-vom-Review-Flow. Standardzeug. Nicht-standardmäßig kaputt.

Die Fehlerliste, als ich den Durchlauf startete:

Die Enter-Taste brachte das Formular auf Textarea-Seiten nicht weiter — nur der explizite Weiter-Button funktionierte
Die Überprüfungsseite lud in etwa 20% der Fälle nicht und zeigte eine leere Komponente
Der Bearbeiten-Button auf der Überprüfungsseite wurde von einem veralteten Modal-Overlay blockiert, wenn man zuvor im Flow ein Modal geschlossen hatte

Vom ersten wusste ich. Die anderen beiden entdeckte ich, weil ich den Agenten laufen ließ.

Das Skript, das Claude Code für sich selbst schrieb, leicht bereinigt:

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,
  });
});

Die Claude Code-Anweisung, die es antrieb, war vier Sätze lang: „Führe den Test aus. Wenn er fehlschlägt, mach einen Screenshot des Fehlerpunkts, lies den Quellcode der fehlschlagenden Komponente, schlage einen Fix vor, wende ihn an, starte den Dev-Server neu und führe den Test erneut aus. Wiederhole, bis der Test dreimal hintereinander besteht. Frag mich bei nichts unter P0."

Der Agent führte den Test aus. Er schlug auf Seite 3 fehl — Enter-Taste, der Bug, den ich kannte. Er öffnete die Textarea-Komponente, fand den onKeyDown-Handler, der event.preventDefault() bedingungslos aufrief, schränkte es ein, Enter nur zu verhindern, wenn Shift gehalten wurde (damit mehrzeilige Eingabe weiterhin funktionierte), speicherte, startete den Dev-Server neu, führte erneut aus. Test bestand Seite 3, schlug auf Seite 4 fehl — die leere Überprüfungsseite. Der Agent vermutete ein Race-Condition zwischen dem Route-Loader und dem Form-State-Hook, fügte einen Ladezustand hinzu, versuchte es erneut. Bestanden. Schlug beim Bearbeiten-vom-Review-Modal-Kollision fehl. Schrieb einen kleinen Effect, der Modal-Overlays bei Routenwechseln aufräumte. Dreimal hintereinander bestanden. Gestoppt. Schrieb eine Zusammenfassung in qa-run.md.

Elf Minuten. Drei echte Bugs gefunden und gepatcht. Ein Mensch, der vom anderen Ende des Raumes beaufsichtigte.

Das Muster, destilliert:

Testen — Playwright CLI führt das Skript aus
Erkennen — Bei Fehlschlag: Screenshot + Quellcode lesen + Hypothese bilden
Beheben — Den Patch anwenden, alles neu starten, was neu gestartet werden muss
Erneut testen — Schleife, bis N Mal hintereinander grün, nicht nur einmal

Die „N Mal hintereinander"-Anforderung leistet viel. Ein flaky Test, der einmal besteht, ist nicht repariert. Drei aufeinanderfolgende Durchläufe ist die kleinste Stichprobengröße, bei der man glaubwürdig sagen kann, dass der Fix gehalten hat.

Das ist wirklich das Nächste, was ich gesehen habe, wie Claude Code sich wie ein Junior-QA-Ingenieur verhält, der das Ticket tatsächlich abschließt. Wenn Sie sehen möchten, wie sich diese Art von Schleife in einen breiteren Engineering-Workflow einfügt, schlüsselt der Beitrag zum Claude Code Skills-Stack die darüberliegenden Ebenen auf — Superpowers, Skill Creator und den Rest. Playwright CLI sind die Augen und Hände. Diese Skills sind das Gehirn.

Muster 2: Adaptives Web-Scraping (wenn Google sich langweilt)

Anderer Job, andere Lektion. Ein Freund, der einen kleinen Zahnarzt-Marketing-Service betreibt, fragte, ob ich Kontaktdaten — Name, Adresse, Telefon — für jeden Zahnarzt in einigen bestimmten kalifornischen Postleitzahlen zusammentragen könnte. Manuelle Recherchezeit pro Postleitzahl: vier bis sechs Stunden. Öffentliche Informationen, nur mühsam zu sammeln.

Das erste Skript, das Claude schrieb, war das naheliegende: Google nach dentist near 94110 abfragen, die SERP parsen, jedes Ergebnis besuchen, die Telefonnummer von der Kontaktseite extrahieren. Es funktionierte. Für etwa dreißig Suchen. Dann servierte Google ein CAPTCHA, dann eine weiche Sperre, dann ein hartes Rate-Limit.

Der Patch war der interessante Teil. Ohne dass ich es promptete, fügte Claude drei Verhaltensweisen hinzu:

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;
}

Allein dieser Fallback — Google → DuckDuckGo bei Blockierung — brachte das Skript von „stirbt nach 30 Suchen" zu „lief sechs Stunden unbeaufsichtigt." DuckDuckGo hat nicht Googles Anti-Bot-Infrastruktur, das SERP-Layout ist einfacher zu parsen, und für eine Abfrage wie „dentist 94110" ist die Ergebnisqualität im Wesentlichen gleichwertig.

Die zweite Anpassung war subtiler. Die Telefonnummer war auf der SERP bei etwa 70% der Zahnarzt-Einträge sichtbar — Google zieht sie aus strukturierten Daten und zeigt sie inline. Der naive Scraper würde diese sichtbare Nummer gerne nehmen und weitergehen. Das Problem: Diese Nummer ist manchmal eine Marketing-Tracking-Nummer, nicht die tatsächliche Leitung des Zahnarztes.

Also aktualisierte Claude die Logik: Selbst wenn eine Telefonnummer auf der SERP sichtbar ist, klicke zur eigenen Kontaktseite des Zahnarztes durch und hole die Nummer von dort. Langsamer pro Datensatz. Höhere Genauigkeit. Die Art von Entscheidung, die ein sorgfältiger Mensch treffen würde und eine schlampige Automatisierung überspringen würde.

Das vollständige Sammelskript lief unter drei Stunden, erfasste ~430 kalifornische Zahnärzte in fünf Postleitzahlen und produzierte eine CSV mit Name, Adresse, Telefon, Website und (wo verfügbar) Öffnungszeiten. Kosten in API-Tokens, mit Playwright CLI zur Verwaltung des Browsers statt MCP: etwa 4,20 $.

Zwei praktische Regeln, die ich jetzt auf jeden Scraping-Job anwende:

Habe immer eine Fallback-Suchmaschine. Google ist die beste Quelle, bis es die schlechteste Quelle ist. Ihr Skript sollte den Übergang erkennen, ohne dass Sie es beaufsichtigen.
Misstraue der SERP bei jedem Datenpunkt mit kommerziellem Wert. Telefonnummern, Preise, Öffnungszeiten — klicke durch und verifiziere. Die zusätzliche Latenz ist günstiger als eine Kontaktliste voller toter Enden.

Wenn Sie etwas Komplexeres als dies bauen, behandelt mein Beitrag zu WebMCP für Chrome-KI-Agenten die Alternative, wenn Sie Chrome-spezifische Protokollfunktionen benötigen, die Playwright nicht bietet.

Das ist das Muster, das tatsächlich verändert hat, was ich denke, dass Claude Code leisten kann.

Öffentliche Seiten zu scrapen ist einfach. Alles hinter einem Login ist die echte Grenze — und die meiste interessante Arbeit findet hinter einem Login statt. Slack-Kanäle. Schulplattformen. Interne Dashboards. SaaS-Produkte, die Sie bezahlen. Die Herausforderung ist nicht, sich einmal einzuloggen. Es ist, eingeloggt zu bleiben, über Durchläufe hinweg, über Tage hinweg, über Browser-Neustarts hinweg, ohne dass Sie jedes Mal Anmeldedaten erneut eingeben müssen.

Playwrights persistenter Kontext ist die Antwort, und die meisten Tutorials liegen falsch, weil sie storageState mit launchPersistentContext verwechseln. Es ist nicht dasselbe.

storageState ist ein Snapshot von Cookies + localStorage, in eine JSON-Datei exportiert. Gut für headless CI-Durchläufe, bei denen man sich einmal einloggt, den State speichert und über Hunderte von Testdurchläufen wiederverwendet.

// 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 ist ein echtes Browserprofil auf der Festplatte. Cookies, Cache, localStorage, IndexedDB, Service-Worker-Registrierungen, alles. Das ist es, was Sie wollen, wenn Sie sich über Sessions hinweg wie ein tatsächlich eingeloggter Benutzer verhalten müssen — nicht nur wie ein eingeloggter Test-Runner.

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.

Das Übergabemuster ist der Teil, der mich ein paar Abende gekostet hat, bis er richtig saß. Erster Durchlauf: sichtbar, manuelles Login, manuelle 2FA, alles manuell, was der Bot nicht kann. Folgedurchläufe: dasselbe userDataDir, aber headless, und Sie sind bereits authentifiziert. Die Cookies, die Session-Tokens, das Device-Fingerprint-Zeug — alles lebt auf der Festplatte in diesem Profilverzeichnis.

Für eine Schulplattform-Automatisierung, die ich gebaut habe — ein tägliches Skript, das Beiträge abruft, die von Klassenkameraden als „Wins" markiert wurden, sie nach Aktualität sortiert und die Top 5 liked — sieht der Durchlauf so aus:

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();
})();

Die Drosselung in der Schleife ist da wegen eines echten Bugs, den ich verursacht habe. Meine erste Version des Skripts klickte alle fünf Likes innerhalb eines Promise.all. Das Frontend der Plattform ist nicht dafür gebaut, fünf gleichzeitige Like-Mutationen aus derselben Session zu verarbeiten, und es crashte den React-Tree mitten im Rendern. Claude fand das heraus, indem es den Screenshot des kaputten Zustands las, das React-Error-Overlay fand, den Stack-Trace las und entschied, dass der Fix eine Verzögerung war und keine Retry-Logik.

Diese iterative Schleife — kaputt, Screenshot, Fehler lesen, Hypothese aufstellen, beheben, erneut ausführen — ist exakt die gleiche Schleife wie bei Muster 1. Andere Domäne, identische Form.

Verbindung zu einem bereits laufenden Browser (CDP)

Es gibt eine dritte Option für das „eingeloggt"-Problem, die es wert ist, sie zu kennen, auch wenn man sie nicht oft nutzt: Playwright mit einer Chrome-Instanz verbinden, die man selbst gestartet hat.

Chrome mit offenem Debugger-Port starten:

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

Dann Claude Code über ein Playwright-Skript damit verbinden lassen:

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();

Wann das nützlich ist: Sie haben sich manuell durch einen komplexen mehrstufigen Auth-Flow navigiert (SSO-Weiterleitungen, Hardware-Key-Aufforderungen, Captchas) und Sie möchten, dass der Agent dort übernimmt, wo Sie aufgehört haben. Sichtbarer Modus, echter Browser, echte Cookies, kein Profilkopieren. Die Einschränkung: CDP funktioniert nur für Chromium-basierte Browser — nicht Firefox oder WebKit.

Ich nutze das vielleicht bei einer von zwanzig Automatisierungen. Aber die Male, in denen ich es tue, löst nichts anderes dasselbe Problem.

Sichtbar vs Headless — Eine Regel, keine Präferenz

Der Standard in CI ist headless. Der Standard während der Entwicklung sollte sichtbar beim ersten Durchlauf jeder neuen Automatisierung sein, dann headless, sobald sie stabil ist.

Der Grund ist Debugging-Asymmetrie. Wenn ein headless Durchlauf fehlschlägt, haben Sie einen Screenshot, einen Trace und Ihre Vorstellungskraft. Wenn ein sichtbarer Durchlauf fehlschlägt, können Sie den tatsächlichen Browser den tatsächlichen Fehler machen in Echtzeit sehen. Der Unterschied zwischen diesen beiden Debugging-Erfahrungen ist der Unterschied zwischen einem Bug in zwanzig Minuten und einem Bug in drei Stunden beheben.

Das Flag ist einfach --headed:

npx playwright test --headed --debug

--debug fügt den Inspector hinzu — bei jeder Aktion pausieren, schrittweise durchgehen, Selektoren live modifizieren. Benutzen Sie es einmal. Sie werden nie wieder zu Print-Debugging bei Playwright zurückkehren.

Die Ausnahme: Jedes Mal, wenn der Agent unbeaufsichtigt läuft, muss er headless sein. Sichtbare Durchläufe brauchen einen Display-Server, werden beendet, wenn Ihre Session endet, und verursachen echten Overhead. Der Ein-Zeilen-Wechsel ist das, was Sie wollen — sichtbar während des Bauens, headless während des Laufens.

Wofür ich Playwright CLI nicht verwende

Das ist der Teil, den die meisten Beiträge überspringen. Drei Dinge, die ich ausprobiert und wieder zurückgenommen habe.

Schweres Netzwerk-/Performance-Debugging. Playwright CLI kann Netzwerkprotokolle und Traces aufzeichnen, aber für ernsthaftes Debugging — Vergleich von Waterfall-Timings, Profiling von JavaScript-Hotpaths, Inspektion von CDP-Level-Events — ist Chrome DevTools MCP wirklich besser. Das Execute-Tool bündelt Aktionen in einen einzelnen Aufruf und die CDP-nativen Daten sind reichhaltiger. Ich habe beides installiert und greife zu DevTools MCP, wenn die Frage „warum ist diese Seite langsam" lautet statt „hat diese Seite funktioniert."

Alles innerhalb von iframes von einem anderen Ursprung. Playwright handhabt Cross-Origin-Iframes, aber die API wird schnell hässlich — frameLocator-Ketten, sorgfältige waitFor-Platzierung und ein permanentes Misstrauen, dass die Selektoren das nächste Deploy nicht überleben. Für Ad-Widgets, eingebettete Stripe/Plaid-Flows oder Social-Login-Popups fange ich entweder auf der Netzwerkebene ab oder automatisiere diesen Schritt einfach nicht. Das Kosten-Nutzen-Verhältnis stimmt nicht.

E-Mail-Bestätigungs-Flows. Playwright klickt gerne auf den Link in der E-Mail, wenn Sie ihm den Link geben. Der schwierige Teil ist, den Link zu bekommen. Mailbox-APIs (Mailtrap, Mailosaur) lösen das; Playwright nicht. Zu versuchen, Gmail nach der Bestätigungs-E-Mail zu scrapen, ist ein Weg zum Schmerz.

Die ehrliche Zusammenfassung: Playwright CLI ist der richtige Standard für Browser-Automatisierung innerhalb von Claude Code im Jahr 2026. Es ist nicht das richtige Tool für Performance-Arbeit, exotische Embed-Flows oder E-Mail-Plumbing. Zu wissen, wo die Grenzen sind, bewahrt Sie davor, sie um 2 Uhr morgens zu lernen.

Eine Browser-Automatisierung, die nur läuft, wenn Sie daran denken, sie auszuführen, ist eine Demo. Produktions-Browser-Automatisierungen laufen nach einem Zeitplan.

Drei Optionen, jede für eine andere Realität geeignet:

Modal — serverloses Python mit erstklassiger Playwright-Unterstützung. Sie definieren eine Funktion mit @modal.function(schedule=modal.Cron("0 9 * * *")) und Modal kümmert sich um den Container, die Browser-Binaries, die Laufisolierung, die Logs. Mein täglicher News-Roundup-Bot läuft hier. Etwa 0,40 $ pro Tag an Rechenleistung.

Trigger.dev — TypeScript-nativ, das JS-Ökosystem fühlt sich näher an, wenn Ihre Playwright-Skripte bereits TS sind. Ihr Browser-Task-Primitiv ist speziell für Playwright-Workloads gebaut.

Desktop-Cron + Headless — für persönliche Automatisierungen auf dem eigenen Laptop. Funktioniert. Bricht zusammen, sobald Ihr Laptop schläft, das WLAN wechselt oder der Browser aktualisiert. Verwenden Sie es für nichts, was wichtig ist.

Ich habe alles mit Desktop-Cron angefangen, weil es kostenlos war. Ich bin nach dem dritten verpassten Durchlauf während eines Fluges zu Modal migriert. Monatliche Gesamtrechnung für vier geplante Bots: unter 25 $. Es lohnt sich.

Die Agenten-Schicht darüber

Sobald Playwright CLI verdrahtet ist und Ihre ersten drei Muster funktionieren, ist die Versuchung, immer größere Skripte zu bauen. Tun Sie das nicht. Der nächste Schritt ist, Agenten zu bauen, die die Skripte aufrufen.

Ein täglicher News-Roundup-Agent, der:

Um 8 Uhr morgens aufwacht
Schlagzeilen von drei RSS-Feeds über einfaches HTTP abruft (kein Browser nötig)
Claude bittet, sie zusammenzufassen und zu ranken
Ein Playwright-CLI-Skript aufruft, um die Zusammenfassung in einen Slack-Kanal zu posten
Den Kanal die nächsten dreißig Minuten über eine persistente Session auf Antworten beobachtet
Claude bittet, Entwürfe für Antworten auf alles zu erstellen, was eine braucht
Ein weiteres Playwright-Skript aufruft, um die Antworten zu posten

Jedes Stück ist klein. Die Browser-Teile sind winzig — ein Klick, eine Eingabe, ein Screenshot, ein Beenden. Das Agenten-Reasoning lebt außerhalb des Browsers. Der Browser ist nur Hände.

Diese Trennung ist der ganze Sinn davon, CLI gegenüber MCP für diese Workflows zu bevorzugen. Die Browser-Schicht sollte günstig, schnell und einfach sein. Die Reasoning-Schicht sollte sein, wo die Tokens hingehen. Wenn die Browser-Schicht auch Tokens durchkaut — was Playwright MCP bei jeder Seite tut — funktioniert die Rechnung in keiner nicht-trivialen Größenordnung mehr.

Die nächstliegende Einordnung, die ich Ihnen geben kann: Playwright CLI verhält sich zur Browser-Automatisierung wie Bash zur Dateisystem-Automatisierung. Klein, scharf, skriptfähig. Leicht zu etwas Größerem zusammenzusetzen. Vergessbar auf die Art, wie gute Infrastruktur vergessbar sein soll.

Häufig gestellte Fragen

Ist Playwright CLI ein Ersatz für Playwright MCP?

Nein — Playwright CLI ist ein Begleitwerkzeug, kein Ersatz. Verwenden Sie CLI, wenn ein Coding-Agent wie Claude Code den Browser steuert; verwenden Sie MCP, wenn ein autonomer Agenten-Workflow das Standard-MCP-Protokoll benötigt. Microsoft pflegt beides bewusst.

Wie viel spart Playwright CLI tatsächlich an Tokens im Vergleich zu Playwright MCP?

Öffentliche Benchmarks und meine eigenen Durchläufe zeigen ungefähr 4x weniger Tokens pro Session mit Playwright CLI gegenüber Playwright MCP. Die Einsparungen kommen daher, dass CLI Snapshots als kompaktes YAML auf die Festplatte speichert, anstatt vollständige Accessibility-Trees bei jeder Interaktion in den Modellkontext zu streamen.

Kann Playwright CLI mich über mehrere Durchläufe eingeloggt halten?

Ja — verwenden Sie chromium.launchPersistentContext(userDataDir, { headless: false }) für das erste manuelle Login, dann führen Sie nachfolgende Automatisierungen mit demselben userDataDir im Headless-Modus aus. Cookies, localStorage und Session-Tokens bleiben alle auf der Festplatte bestehen.

Wann sollte ich stattdessen Chrome DevTools MCP verwenden?

Greifen Sie zu Chrome DevTools MCP, wenn die Aufgabe Performance-Profiling, Netzwerk-Waterfall-Analyse oder tiefes CDP-Level-Debugging erfordert. Es ist auch token-effizienter als Playwright MCP für diese spezifischen Workloads. Für reine Automatisierung und QA-Schleifen gewinnt Playwright CLI.

Kann Claude Code Playwright-Skripte von Grund auf schreiben?

Ja — und es ist zuverlässig. Verwenden Sie npx playwright codegen <url>, um eine erste Session aufzuzeichnen, wenn Sie das Skript vorbereiten möchten, und lassen Sie dann Claude es verfeinern. Für die meisten Automatisierungen beschreibe ich das Ziel in 2-3 Sätzen und das funktionierende Skript ist geschrieben, bevor ich meinen Kaffee ausgetrunken habe.

Die elf Minuten, die verändert haben, wie ich entwickle

Zurück zum Onboarding-Formular. Elf Minuten, drei echte Bugs gefunden und behoben, null Tastatureingaben von mir. Was mich immer wieder beschäftigt, ist nicht die Geschwindigkeit — es ist, dass die Schleife sich selbst geschlossen hat. Der Agent hat nicht Code geschrieben und aufgehört. Er hat Code geschrieben, den Test ausgeführt, den Fehler gesehen, die Ursache zurückverfolgt, den Fix angewandt und den Test erneut ausgeführt, bis das Ergebnis dem Ziel entsprach.

Diese geschlossene Schleife ist das, was Browser-Automatisierung endlich wie Infrastruktur anfühlen lässt statt wie Theater. Playwright CLI hat die Schleife nicht erfunden. Es hat sie günstig genug gemacht, um sie auszuführen.

Nehmen Sie sich heute Abend eines der drei Muster aus diesem Beitrag vor. Die QA-Schleife ist am einfachsten zu starten — richten Sie Claude auf eine beliebige formular-intensive App, die Sie pflegen, geben Sie ihm die Vier-Satz-Anweisung von vorhin, gehen Sie zehn Minuten weg. Kommen Sie zurück. Sehen Sie, was es gefunden hat. Wenn die Schleife zum ersten Mal einen echten Bug findet, von dem Sie nichts wussten, werden Sie verstehen, warum ich meine Arbeitsweise geändert habe.

Lassen Sie uns zusammenarbeiten

Sie möchten KI-Systeme aufbauen, Workflows automatisieren oder Ihre technische Infrastruktur skalieren? Ich helfe Ihnen gerne.

Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
Portfolio: mejba.me
Ramlit Limited (Enterprise-Lösungen): ramlit.com
ColorPark (Design & Branding): colorpark.io
xCyberSecurity (Sicherheitsdienstleistungen): xcybersecurity.io

Playwright CLI in Claude Code: Autonome Browser-Bots