Mein KI-Agent scheiterte 30 Mal am gleichen LinkedIn-Klick. Camoufox schaffte es beim ersten Versuch.
Manchmal macht die KI einfach was Dummes. Egal, wie du sie promptest.
Derselbe Klick, 30 Mal
Mein Agent ist 30 Mal beim gleichen LinkedIn-Klick gescheitert und hat denselben Button auf derselben Seite in einer endlosen Retry-Schleife geklickt. LinkedIn-Profile zeigen „Folgen" als primäre Aktion und „Vernetzen" versteckt in einem „Mehr"-Overflow-Menü (die 3 Punkte). Du tippst auf das Overflow, das Menü erscheint, du klickst „Vernetzen", der Verbindungsdialog öffnet sich. Eigentlich simpel.
Das Chrome MCP macht einen Screenshot, um die Position des Elements zu lesen, dann sendet es den Klick. Diese Sequenz hat eine Verzögerung. Kurz, aber nicht komprimierbar. Bis das Klick-Event ausgelöst wird, hat sich das animierte Overflow-Menü bereits selbst geschlossen. Der Agent erkennt das nicht. Er macht einen weiteren Screenshot, sieht keinen „Vernetzen"-Dialog, springt zurück. Bei Versuch 14 zeigen die Logs exakt dieselbe Sequenz. Versuch 20 ist nur noch Rauschen.
Irgendwann sitze ich da, lese die Logs und denke mir, das Ding wird mich sperren lassen. (Dark Souls-Energie: du stirbst, du versuchst es, du stirbst wieder. Außer dass ein LinkedIn-Bann keine Respawn-Situation ist.)
Das Chrome MCP ist kein schlechtes Tool. Das will ich klarstellen, bevor ich weitermache, denn nach so einer Session ist es leicht, in „das Tool ist Mist" zu verfallen. Für 80% der Browser-Automatisierungsaufgaben ist es die richtige Standardwahl. Das Problem war, dass der LinkedIn-Overflow-Menü-Fall nicht in diesen 80% lag, und das Signal zum Wechseln war bereits bei Versuch 2 da.
Was Chrome MCP tatsächlich gut kann (Die 80%)
Das Wiederverwenden einer bestehenden Session ist unschlagbar bei Chrome MCP. Der Browser ist bereits authentifiziert, Cookies geladen, 2FA erledigt. Der Agent springt in diesen Kontext, ohne Login- oder Verifizierungsflows anzufassen.
Navigation und Textextraktion sind zuverlässig. DOM-Inhalte lesen, strukturierte Seiten scrapen, Text aus stabilen Layouts ziehen: solide.
Standard-HTML-Formulare funktionieren sauber. Textfelder, Dropdowns, Checkboxen: das MCP füllt sie ohne Umstände, keine JavaScript-Gymnastik erforderlich.
Frontend-Debugging ist der unterschätzte Fall. Der Agent kann Konsolenfehler, Network-Waterfall und Live-Seitenstatus lesen. Nützlich, wenn du etwas baust und willst, dass der Agent seine eigene Ausgabe im Browser verifiziert, ohne ein separates Test-Harness aufzusetzen. Denk daran wie Pair Programming, wo 1 Partner nur über Screenshots kommuniziert. Ineffizient für die meisten Gespräche, überraschend okay für Code Review.
Diese 4 Fälle decken den Großteil dessen ab, was jeder Browser-Automatisierungs-Workflow täglich braucht. Die Edge Cases tauchen auf, wenn die Aktion präzises Timing oder native Event-Behandlung erfordert.
Die 4 Arten, wie es kaputt geht
Der LinkedIn-Fall produzierte 4 verschiedene Fehlermodi bei derselben Aktion. Jeder läuft anders ab.
Das Menü schließt sich, bevor der Klick ankommt. Der Overhead zwischen Screenshot und Klick-Dispatch ist nicht komprimierbar. Für eine CSS-Transition, die sich in 150ms schließt, reicht dieser Overhead. Das Menü ist weg, bevor der Klick ankommt.
Synthetische Klicks werden stillschweigend ignoriert. LinkedIns artdeco-Komponentenbibliothek lauscht auf vertrauenswürdige Pointer-Events, die durch echte Hardware-Eingabe generiert werden. Ein programmatisch gesendeter Klick trägt nicht das isTrusted-Flag. Die Komponente reagiert nicht. Kein Fehler, kein Feedback, nichts.
Das Element wird vom Sticky Header verdeckt. LinkedIns Navbar bleibt oben im Viewport fixiert. Wenn sich das Overflow-Menü nahe dem oberen Seitenrand öffnet, fängt die Navbar den Klick ab. Chrome MCP führt keinen Hit-Test durch, um das zu erkennen.
Der Tab driftet ab. Nach genug parasitären Klicks aktiviert sich etwas: eine Karte, ein Profil-Link, ein Sidebar-Panel. Der Agent verliert die Zielseite und automatisiert selbstbewusst das, worauf er gelandet ist. (Gesponserte Networking-Veranstaltung akzeptiert. Danke, Agent.)
Jeder davon ist einzeln lösbar. Alle 4 zusammen bei derselben Aktion sind eine strukturelle Mauer.
Warum es kaputt geht (Es liegt nicht am Prompt)
Das Chrome MCP operiert von oberhalb des Browsers. Es sitzt als Extension, beobachtet durch Screenshots, sendet 1 Aktion pro Zyklus und wartet. Dieses Modell hat einen echten Vorteil: es erfordert keine Installation in der Rendering-Engine, es nutzt deine bestehende Chrome-Session ohne Modifikation wieder, und du kannst es auf jede laufende Chrome-Instanz ohne Setup richten. Der Tradeoff ist, dass jede Aktion einen Round-Trip mit genug Latenz beinhaltet, um zeitkritische UI-Zustände zu verlieren, und die Klicks, die es sendet, stammen nicht aus der vertrauenswürdigen Event-Pipeline.
Moderne JavaScript-Frameworks prüfen die isTrusted-Eigenschaft bei eingehenden Pointer-Events, und React, Vue und Komponentenbibliotheken wie LinkedIns artdeco machen alle diese Prüfung. Ein Chrome MCP-Klick landet im DOM, scheitert aber an der internen Validierung der Komponente. Der Fehler ist stumm, kein Error taucht auf, und du müsstest den Komponenten-Source lesen, um überhaupt zu wissen, dass die Prüfung existiert.
Ich habe 3 Wochen damit verbracht, speziell die Timing-Seite zu fixen: wait_for_element, Retry-Gaps erhöhen, verschiedene Delay-Werte zwischen Screenshot und Klick. Das Menü schloss sich weiter. Das isTrusted-Problem war komplett separat und ich fand es erst heraus, nachdem ich den artdeco-Source gelesen hatte. Das war ein spaßiger Donnerstag.
Warum CLIs oft MCP für Agent-Arbeit schlagen behandelt die Token-Kosten-Seite dieses Tradeoffs, aber die Trusted-Event-Seite ist das, was in der Produktion wirklich beißt.
Ein Chrome MCP-Klick ist technisch ein Klick. Die Komponente behandelt ihn wie eine höfliche E-Mail, die niemand angefordert hat.
Das Wechsel-Signal: 2 bis 3 Fehlschläge
Die Regel ist 1 Zeile: nach 2 bis 3 Fehlschlägen bei derselben spezifischen Aktion, stopp und wechsle das Tool. Eine weitere Retry-Schleife hinzuzufügen ändert das Ergebnis nicht, wenn der Fehler strukturell ist.
Nach dem 3. gescheiterten Versuch bei derselben Geste debuggst du nicht den Ansatz. Du levelst deine Log-Datei auf.
Die Situationen, die den Wechsel auslösen:
- Ein Menü oder Overlay schließt sich, bevor der Klick ankommt
- 2 Gesten müssen in einem engen Zeitfenster verkettet werden (Menü öffnen, dann Item klicken)
- Das Element reagiert nicht auf Klicks und zeigt keinen Fehler
- Ein React- oder Vue-Button bleibt ausgegraut, obwohl das Formular gültig erscheint
- Dieselbe Aktion muss dutzende Male im Headless-Modus laufen
Ich denke, diese 2-bis-3-Schwelle gilt für die meisten Standard-Web-UIs. Weniger sicher, ob sie gleich für vollständig custom Frameworks gilt, wo Fehlermodi anders aussehen.
Was Camoufox ändert (Und was es kostet)
Camoufox ist ein Firefox-Browser, gehärtet gegen Bot-Erkennung, gesteuert von Playwright. Wo Chrome MCP von oberhalb des Browsers operiert, injiziert Playwright Events von innerhalb der Rendering-Engine, durch denselben Pfad, den echte Benutzereingaben nehmen.
Beim LinkedIn-Overflow-Fall:
Echte vertrauenswürdige Events. Playwright sendet die vollständige Pointer-Event-Kette mit isTrusted: true. Das Overflow-Menü öffnet sich. Das „Vernetzen"-Item registriert den Klick. Erstes Profil erledigt.
ARIA-basierte Locators. Statt Screenshot-Pixel-Koordinaten: page.getByRole('menuitem', { name: 'Connect' }). Deterministisch, lesbar und bricht nicht, wenn LinkedIn ihr Padding um 2 Pixel in einem Montag-Wartungsfenster anpasst. Jedes Team hatte diesen Deploy 😅
Kein Round-Trip zwischen Aktionen. Öffne das Menü und klicke das Item in derselben Script-Ausführung. Kein Screenshot-Zyklus zwischen den 2 Schritten. Keine Race Condition.
React-State-Validierung. Für einen Submit-Button, der ausgegraut bleibt, bis das Input einen Wert hat: Playwright sendet sowohl die input- als auch change-Events, um den Komponenten-State zu wecken, dann klickt den entsperrten Button. Chrome MCP klickt den ausgegrauten Button. Nichts passiert.
Sofort die Nachteile. Die Session überträgt sich nicht: der erste Start erfordert einen manuellen Login, da Camoufox Chromes Cookies nicht erbt. Ein neuer Browser-Fingerprint löst LinkedIns „neues Gerät"-Verifizierung aus. Das Playwright-Script ist Produktionscode, der gewartet werden muss. Und LinkedIns Rate Limiting ist egal, welchen Browser du verwendest, wenn die Aktions-Kadenz automatisiert aussieht.
Der Wechsel hat echte Setup-Kosten. Er zahlt sich aus, wenn Chrome MCP bereits 2 bis 3 Fehlschläge bei einer spezifischen Aktion gezeigt hat. Nicht vorher. Playwright basiert auf Chrome DevTools Protocol, weshalb das Event-Modell viel näher an echter Benutzereingabe ist als alles, was von oberhalb des Browsers operiert.
Wann was verwenden
Chrome MCP für:
- Schnelle einmalige Aufgaben auf Seiten, in die du bereits eingeloggt bist
- Inhalte von stabilen Seiten lesen
- Formulare auf Standard-HTML-Inputs ausfüllen
- Frontend-Issues in einer bestehenden Session debuggen
Camoufox + Playwright für:
- Wiederholte Aktionen, die zuverlässig sein müssen
- Interaktive Elemente, die vertrauenswürdige Events erfordern
- Enge Timing-Sequenzen (Menüs, Dropdowns, Modals)
- Produktions-Automatisierung, die sich keine Retry-Schleifen leisten kann
Der Wechsel-Trigger: 2-3 Fehlschläge bei derselben spezifischen Aktion. Nicht 30.
Die 30-Versuch-Session kostete 40 Minuten und ein Playwright-Script-Rewrite. Camoufox schaffte das erste Profil in 12 Sekunden. Die 29 danach liefen im gleichen Tempo.
Das Signal war bei Versuch 2 da. Ich brauchte nur 28 weitere Versuche, um es zu lesen. 🤦♂️
Quellen
- Camoufox: Firefox-Browser gehärtet für Automatisierung, basiert auf Playwright
- Playwright-Dokumentation: Browser-Automatisierungsbibliothek
- Chrome DevTools Protocol: offizielle CDP-Spezifikation
Dieser Post kann Affiliate-Links enthalten. Wenn du sie klickst, verdiene ich möglicherweise eine kleine Provision. Kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern.