Launch dein SaaS mit einem Browser-Agenten auf Verzeichnissen

Was ein Browser-Agent braucht

Zugriff auf die Repository-Dateien

Der Agent muss das Playbook einer Plattform, product.json und identity.json lesen. Ein Coding-Agent mit Browser-Tool liest sie direkt; ein rein gehosteter Browser-Agent braucht dich, um ihm pro Plattform das passende Playbook und die Produktfakten zu geben.

Ein Browser, in dem du eingeloggt bist

Einreichungen passieren mit deinen Accounts. Ein Browser-Agent, der in seinem eigenen Remote-Browser läuft, ist nicht als du eingeloggt und kann dein Postfach nicht nach Verifikationscodes lesen; die Anleitung im Repository geht von einem Chrome aus, den du sehen kannst.

Eine Möglichkeit, Ergebnisse zu erfassen

record.py und das lokale Dashboard sind Python-Skripte auf deinem Rechner. Kann der Browser-Agent sie nicht ausführen, erfasst du jedes Ergebnis nach dem Lauf selbst im Dashboard.

Die Stop-Bedingungen des Runbooks

Erst Duplikatsuche, Identitätsprüfung pro Plattform, keine Käufe, Stopp bei CAPTCHA oder Unklarheit. Das sind Anweisungen, die der Agent tatsächlich befolgen muss, keine Funktionen, die er mitbringt.

Einen Browser-Agenten mit deinem Chrome verbinden

BROWSER-SETUP.md ist für Agenten geschrieben, die sich an einen Chrome hängen, den du beaufsichtigst. Ist dein Browser-Agent ein Coding-Agent mit Browser-Tool, gilt die Anleitung unverändert: Chrome DevTools MCP mit Auto-Connect an deinem Alltags-Chrome (144 oder neuer) oder ein dediziertes Chrome-Profil mit lokalem Debugging-Port, eine langlebige Verbindung pro Batch.

Ein Agent, der nur seinen eigenen Remote-Browser anbietet, erfüllt die unterstützte Verbindungsvoraussetzung nicht. Richte Chrome DevTools MCP mit deinem lokalen Chrome ein und mach vor dem Start den sichtbaren Smoke-Check.

Schließ sensible Tabs ohne Bezug zum Launch, nutze nur die für das Produkt freigegebenen Seiten, exportiere nie Cookies oder ein Browser-Profil und behandle einen abgeschlossenen Tool-Call als nicht mehr als einen Tool-Call — lies die Seite zurück, um zu sehen, ob gespeichert wurde.

Ist dein Browser-Agent ein Coding-Agent mit Browser-Tool, ist das hier die allgemeine Server-Definition aus BROWSER-SETUP.md. Dein Agent speichert sie vielleicht in einer anderen Datei oder einem anderen Format; wohin sie gehört, bestimmt seine eigene Setup-Oberfläche:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--autoConnect",
        "--no-usage-statistics",
        "--no-performance-crux"
      ]
    }
  }
}

Format wie von github.com dokumentiert, geprüft am 30. September 2026. ↗

Ein Agent, der einen solchen Server nicht laden kann, ist nicht auf dem unterstützten Weg. Er kann trotzdem ein einzelnes Formular anhand eines Playbooks ausfüllen, das du einfügst, und das Ergebnis trägst du selbst im Dashboard ein.

Deinen Coding-Agenten mit deinem Chrome verbinden →

Der Start-Prompt

Der öffentliche Start-Prompt aus START.md, unverändert. Er setzt einen Agenten voraus, der im geklonten Ordner Python ausführen kann — typischerweise ein Coding-Agent mit Browser-Tool. Bei einem rein gehosteten Browser-Agenten führst du stattdessen die „doing it yourself“-Befehle aus START.md in deinem Terminal aus und nutzt das Dashboard, um dem Agenten Prompts pro Plattform zu kopieren.

Recommend Claude Code CLI or Codex CLI in a terminal instead of the desktop apps for best results. If session metadata confirms desktop hosting, explicitly advise me to switch to the CLI and resume this same private workspace. Do not infer the host from a CLI engine version alone.

Read AGENTS.md, then follow "Start the dashboard for the owner". Create my private
workspace if I do not have one yet, start the dashboard, and give me the link.
Then lead ONBOARDING.md one phase at a time. Reuse recorded permissions instead of
asking again unless their scope is missing or conflicting. Actually test my visible
existing Chrome profile and intended identity as BROWSER-SETUP.md requires; use the
OS fallback if needed. Use one platform/browser worker by default. Build the normal
run only from suitable free-ready routes, keep research separate, and preserve any
draft that needs one exact human CAPTCHA/2FA action. Never claim browser control
bypasses or reduces those challenges.

Playbooks und Anweisungen sind englisches Markdown — das können Coding-Agenten am besten. Deine Produkttexte dürfen in jeder Sprache sein, die ein Verzeichnis akzeptiert; der Agent antwortet dir in deiner Sprache.

So oder so landen Workspace, product.json, authorizations.json und submissions.json als Dateien auf deinem Rechner, und das Dashboard zeigt, was live, ausstehend oder geplant ist oder auf dich wartet.

LaunchRepo in drei Schritten starten →

Wie ein Lauf aussieht

Die Illustration unten ist die von der Startseite: ein Batch, jede Plattform endet in dem Zustand, der tatsächlich beobachtet wurde. Bei einem Browser-Agenten trägst du die Zustände vielleicht nach dem Lauf selbst ein; so oder so kommen sie aus dem Tracker, nicht von dieser Seite.

Wenn ein Browser-Agent festhängt

Browser-Agenten scheitern anders als Coding-Agenten. Diese drei Situationen solltest du früh erkennen, bevor ein Batch aus dem Ruder läuft:

Er ist nirgends eingeloggt

Der Agent arbeitet in seinem eigenen Remote- oder verwalteten Browser. Deine Verzeichnis-Accounts und dein Postfach sind in deinem Chrome, verlege den Lauf also per Chrome DevTools MCP dorthin oder behandle die Arbeit des Agenten als Entwurf, den du selbst fertigstellst.

Eine Seite lässt ihn nicht rein

Manche Seiten schränken automatisierte Agenten in gehosteten Browsern ein, obwohl sie in deinem eigenen problemlos funktionieren. Markiere die Plattform als „braucht dich“ und reiche sie mit geöffnetem Playbook von Hand ein.

Er hat vergessen, was er beim letzten Mal getan hat

Browser-Agenten führen selten Buch über mehrere Sessions hinweg. Trag jedes Ergebnis direkt nach dem Lauf im Dashboard ein; der nächste Batch startet dann vom Tracker aus statt aus dem Gedächtnis.

Laufen Browser-Tools mit --autoConnect in ein Timeout, prüfe vier Dinge: Chrome 144 oder neuer läuft bereits, Remote-Debugging ist unter chrome://inspect/#remote-debugging eingeschaltet, du hast die Verbindungsanfrage von Chrome erlaubt, und kein anderes Tool hält denselben Browser. Chrome DevTools MCP lädt jeden offenen Tab, schließ also die, die du nicht brauchst.

Was weiterhin dich braucht

LaunchRepo ist bewusst kein Hintergrunddienst. Diese Momente stoppen den Lauf und werden als Übergabe an den Menschen erfasst; der Agent arbeitet nie um sie herum:

CAPTCHAs und Bot-Prüfungen

Egal welcher Agent, die Prüfung löst du im vorgesehenen Fenster. Der Tracker erfasst prepared_needs_human; in keinem Playbook gibt es Stealth- oder Umgehungsschritte.

2FA und Verifikationscodes

Die meisten Verzeichnisse bestätigen per E-Mail. Kann der Browser-Agent dein Postfach nicht lesen, sind Code und Bestätigungsklick eine Übergabe an den Menschen — als solche erfasst, nie als automatisierter Zugriff.

Kostenpflichtige Upsells

Wege, die nur gegen Bezahlung gehen, werden als deferred_paid erfasst. Einem Browser-Agenten muss man sagen, dass er nicht kauft; die Playbooks sagen es auf jeder Plattform, und die Entscheidung bleibt bei dir.

Erfassen und bestätigen

Kann der Agent record.py nicht ausführen, trägst du das Ergebnis im lokalen Dashboard ein. „Live“ braucht immer eine öffentliche URL und deine Bestätigung.

Kein Benchmark, kein Ranking: Wir nennen Browser-Agenten kompatibel, wenn sie die zwei Anforderungen oben erfüllen, nicht weil wir sie gegen andere Agenten gemessen hätten.

Fragen