browser-integrations: Browserbase on Runloop example (Python + TypeScript)

[vadim-rl]

Browserbase on Runloop: Cloud Browsers for Devbox Agents

Adds a runnable browser-integrations/browserbase example, the companion to the Browserbase on Runloop docs tutorial (docs PR forthcoming).

Key architectural choice

The browser runs on Browserbase, not in the devbox. The agent runs in a Runloop devbox and connects a Playwright client over CDP to the session's connect_url, so there is no Chromium and no playwright install in the devbox, only the browserbase SDK + the Playwright client.

What's here

A research crawl (run) in both languages: an agent in a devbox drives one Browserbase browser to scan seed sites and bring back structured data plus per-seed screenshots.

• python/: python main.py {create-blueprint | run} (a browserbase_runloop package + main.py)
• typescript/: npm run {create-blueprint | run-browserbase} (TS orchestrator; the in-devbox agent is Python, embedded in src/config.ts)

Verification

• Every SDK call verified against the installed runloop_api_client, browserbase, playwright, @runloop/api-client, and @browserbasehq/sdk.
• ruff clean; tsc clean.
• Run live end to end (blueprint build, devbox provision with bounded wait, 6-site / ~70-page crawl over CDP, screenshots downloaded, devbox torn down) in both Python and TypeScript.

[tode-rl]

Live verification now passes with the updated Browserbase project ID, but I found one setup-path issue worth fixing before merge.

First-time create-blueprint can fail even though the blueprint continues building and later succeeds. In my run, python main.py create-blueprint raised PollingTimeout: Exceeded maximum attempts (120) while the newly-created browserbase-browser blueprint was still building; a later status check showed the same blueprint as build_complete, and subsequent Python/TypeScript create-blueprint runs reused it successfully.

The code only reuses build_complete blueprints and otherwise starts a fresh create with the SDK default polling window, so a user can see a failed first-run command or create duplicate builds if they rerun while the original build is still pending. Consider either detecting/reusing an existing building blueprint and waiting for it, or passing a longer polling config for blueprint creation.

Refs: browser-integrations/browserbase/python/browserbase_runloop/create_blueprint.py:19, browser-integrations/browserbase/python/browserbase_runloop/create_blueprint.py:45, browser-integrations/browserbase/typescript/src/create-blueprint.ts:25, browser-integrations/browserbase/typescript/src/create-blueprint.ts:60.

[vadim-rl]

Thanks Tony, good catch. Fixed in 4ce7fcf.

create-blueprint now reuses a finished blueprint, and if one is still building it waits for that build (await_build_complete / awaitBuildComplete) instead of failing or starting a duplicate. Both the create and the wait use a generous polling window (900s, 10k attempts), so a slow first build no longer raises PollingTimeout. Applied to both the Python and TypeScript examples; tests and tsc pass.