Launch your SaaS on directories with a browser agent

What a browser agent needs

Access to the repository files

The agent must read the playbook for a platform, product.json and identity.json. A coding agent with a browser tool reads them directly; a pure hosted browser agent needs you to hand it the relevant playbook and product facts per platform.

A browser you are signed in to

Submissions happen with your accounts. A browser agent that runs in its own remote browser is not signed in as you and cannot read your mailbox for verification codes; the repository’s guide assumes a Chrome you can see.

A way to record outcomes

record.py and the local dashboard are Python scripts on your machine. If the browser agent cannot run them, you record each outcome yourself in the dashboard after the run.

The runbook’s stop conditions

Duplicate search first, identity check per platform, no purchases, stop on CAPTCHA or ambiguity. These are instructions the agent must actually follow, not features it ships with.

Connecting a browser agent to your Chrome

BROWSER-SETUP.md is written for agents that attach to a Chrome you supervise. If your browser agent is a coding agent with a browser tool, the guide applies as-is: Chrome DevTools MCP with auto-connect on your everyday Chrome (144 or newer), or a dedicated Chrome profile with a local debugging port, one long-lived connection per batch.

An agent that only offers its own remote browser does not meet the supported connection requirement. Configure Chrome DevTools MCP with local Chrome and perform the visible smoke check before starting.

Close unrelated sensitive tabs, use only the product’s permitted sites, never export cookies or a browser profile, and treat a completed tool call as nothing more than a tool call — read the page back to see whether it saved.

If your browser agent is a coding agent with a browser tool, this is the generic server definition from BROWSER-SETUP.md. Your agent may keep it in another file or format; its own setup screen decides where it goes:

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

Format as documented by github.com, checked on September 30, 2026. ↗

An agent that cannot load a server like this is not on the supported route. It can still fill a single form from a playbook you paste, and you record the result in the dashboard yourself.

Connect your coding agent to your Chrome →

The start prompt

The public start prompt from START.md, unchanged. It assumes an agent that can run Python in the cloned folder — a coding agent with a browser tool, typically. With a pure hosted browser agent, run the “doing it yourself” commands from START.md in your terminal instead and use the dashboard to copy per-platform prompts to the agent.

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.

The playbooks and instructions are English Markdown, which is what coding agents handle best. Your product copy can be in any language a directory accepts; the agent answers you in your language.

Either way the workspace, product.json, authorizations.json and submissions.json end up as files on your machine, and the dashboard shows what is live, pending, scheduled or waiting on you.

Start LaunchRepo in three steps →

What a run looks like

The illustration below is the home page’s: one batch, each platform ending in the state that was actually observed. With a browser agent the states may be entered by you after the run; either way they come from the tracker, not from this page.

When a browser agent gets stuck

Browser agents fail in different ways from coding agents. These are the three situations to recognize early, before a batch goes sideways:

It is signed in nowhere

The agent is working in its own remote or managed browser. Your directory accounts and your mailbox are in your Chrome, so move the run there through Chrome DevTools MCP, or treat the agent’s work as a draft you finish yourself.

A site refuses it

Some sites restrict automated agents in hosted browsers even though they work fine in your own. Mark the platform as needing you and submit it by hand with its playbook open.

It forgot what it did last time

Browser agents rarely keep a record between sessions. Enter each outcome in the dashboard right after the run; the next batch then starts from the tracker instead of from memory.

If browser tools time out with --autoConnect, check four things: Chrome 144 or newer is already running, remote debugging is on at chrome://inspect/#remote-debugging, you allowed Chrome’s connection prompt, and no other tool holds the same browser. Chrome DevTools MCP loads every open tab, so close the ones you do not need.

What still needs you

LaunchRepo is deliberately not a background service. These moments stop the run and are recorded as human handoffs; the agent never works around them:

CAPTCHAs and bot checks

Whatever the agent, the challenge is yours to solve in the intended window. The tracker records prepared_needs_human; there are no stealth or evasion steps in any playbook.

2FA and verification codes

Most directories confirm by email. If the browser agent cannot read your mailbox, the code and the confirmation click are a human handoff — recorded as such, never as automated access.

Paid upsells

Paid-only routes are recorded as deferred_paid. A browser agent must be told not to buy; the playbooks say it on every platform, and the decision stays yours.

Recording and confirming

If the agent cannot run record.py, you enter the outcome in the local dashboard. “Live” always needs a public URL and your attestation.

No benchmark, no ranking: we call browser agents compatible when they meet the two requirements above, not because we measured them against other agents.

Questions