Browserbase Share: What It Means for Hosted Browser Sessions

# Browserbase Share: What It Means for Hosted Browser Sessions

"Browserbase share" gets searched for a few different reasons. Some developers want to hand a live session to a teammate. Others are looking at how Browserbase lets you share session state, profiles, or a debugging URL across a team. A third group is comparing Browserbase against other hosted runtimes and wants to know what "share" actually buys them in production.

This post answers that directly: what sharing a browser session means, why it matters for AI agents, and how the same capability maps onto Remote Browser's hosted Chromium runtime. If you are evaluating runtimes, the useful question is not "does it have a share button" but "can I hand off a live session, keep its state, and let another process or person pick it up without losing context."

What "Browserbase share" usually refers to

Browserbase is a hosted browser platform. When people talk about sharing in that context, they usually mean one of three things:

• Sharing a live session for debugging. You get a URL that opens the running browser so a human can watch what the agent is doing.
• Sharing session state across runs. Cookies, localStorage, and login state persist so a second run does not start from zero.
• Sharing access across a team or service. Multiple workers or people connect to the same browser context through CDP or an SDK.

These are related but not the same. A live viewer is a debugging convenience. Persistent state is a correctness requirement. Shared access is an architecture decision. Conflating them is where a lot of production setups go wrong.

The reason "share" matters at all is that browser automation stopped being a single-script job. An agent that logs in, navigates, fills a form, and reads a result is a stateful process. If you cannot share that state — between retries, between workers, or between the agent and a human reviewer — you rebuild it every time, and rebuilds are where flakiness lives.

Why session sharing is a production concern, not a feature checkbox

A local Playwright script holds its browser in memory. The session is the process. When you move to a hosted runtime, the browser lives somewhere else, and "the session" becomes an addressable resource with a lifecycle. That shift is what makes sharing both possible and necessary.

Three concrete situations where sharing decides whether your system works:

Retries after a partial failure. An agent gets through login and three steps, then a selector breaks. If the session state is gone, the retry re-authenticates, re-triggers any rate limits, and may hit a CAPTCHA it already cleared. If the session is shareable and persistent, the retry resumes.

Human-in-the-loop review. Some workflows need a person to confirm a step — a payment, a legal form, a flagged page. The agent pauses, a human opens the live session, acts, and hands control back. Without a shared live view, this becomes a screenshot-and-email loop.

Parallel workers on one identity. If two workers need the same logged-in profile, they cannot each spin up a fresh browser and hope the site does not notice. They need to attach to a shared context, or serialize access to it.

None of these are exotic. They are the normal shape of agent workloads once you leave the demo stage.

How sharing works on a hosted Chromium runtime

On Remote Browser, a session is a hosted Chromium instance you connect to over CDP. Sharing is not a separate product surface — it falls out of how sessions, profiles, and connections are modeled.

• Live viewer. Each session exposes a view you can open in a browser to watch the agent in real time. This is the debugging half of sharing.
• Persistent profiles. Session state — cookies, storage, auth — can be attached to a profile that outlives a single run. A new session that mounts the same profile starts where the last one left off.
• CDP access. Because you connect over the Chrome DevTools Protocol, any CDP-capable client can attach: Playwright, Puppeteer, Selenium, or your own tooling. That is what makes "share" meaningful across languages and frameworks.
• Session isolation. Sessions are isolated by default. Sharing is opt-in through profiles or explicit connection, not an accident of co-tenancy.

The practical upshot: you can run an agent in one process, attach a debugger from another, and resume from a stored profile on a third — all against the same underlying browser context.

If you want the broader architecture, the Remote Browser for AI agents guide covers the runtime layer in more depth.

Connecting to a shared session with Playwright over CDP

The mechanism behind most sharing is CDP. Here is the pattern in TypeScript: connect to a hosted session, do work, and keep the context alive so another client can attach.

import { chromium, Browser, BrowserContext, Page } from "playwright";

// Connection URL comes from your runtime's session API.
// Treat it like a secret — it grants control of the browser.
const CDP_URL = process.env.REMOTE_BROWSER_CDP_URL!;

async function attachAndWork(): Promise<void> {
  // connectOverCDP attaches to an existing browser instead of launching one.
  const browser: Browser = await chromium.connectOverCDP(CDP_URL);

  // A hosted session usually has one default context. Reuse it so
  // cookies and storage persist for whoever attaches next.
  const context: BrowserContext = browser.contexts()[0]
    ?? await browser.newContext();

  const page: Page = context.pages()[0] ?? await context.newPage();

  await page.goto("https://example.com/dashboard", {
    waitUntil: "domcontentloaded",
  });

  // Do agent work here. The session stays alive after this script exits
  // as long as the runtime keeps it open — that is what makes it shareable.
  const title = await page.title();
  console.log("Attached to:", title);

  // Do NOT call browser.close() if you want the session to persist
  // for another worker or a human reviewer. Disconnect instead.
  await browser.close();
}

attachAndWork().catch((err) => {
  console.error("Session attach failed:", err);
  process.exit(1);
});

Two details matter for sharing. First, connectOverCDP attaches rather than launches, so you inherit whatever state the session already has. Second, whether you call browser.close() decides if the session dies or stays available. On a hosted runtime, closing the client connection and closing the session are different operations — check your runtime's session lifecycle before assuming a disconnect ends the browser.

For the protocol-level details, the Chrome DevTools Protocol documentation is the authoritative reference, and Playwright's connectOverCDP docs cover the client side.

Sharing models compared

Not every "share" is the same. Here is how the common models differ, and what each is good for.

The pattern to notice: the more you share, the more you need to think about concurrency. Two clients reading the same page is fine. Two clients clicking the same button is a bug waiting to happen. If you need parallel workers on one identity, serialize the write path or give each worker its own session and share only the profile.

What to check before you rely on sharing

If sharing is going to be part of your architecture, evaluate these before you commit:

• Session lifecycle controls. Can you keep a session open after your script exits? Can you explicitly end it? If the only option is "the process holds it," sharing is fragile.
• Profile semantics. Does mounting a profile copy state or reference it? Concurrent mounts of the same profile can corrupt state if the runtime does not lock it.
• Connection limits. How many clients can attach to one session? Some runtimes allow one, some allow many, and the answer changes your design.
• Isolation guarantees. Are sessions isolated by default, with sharing opt-in? Shared-by-default is a security problem.
• Viewer access control. If a live viewer URL exists, who can open it, and does it expire?
• Usage accounting. Shared sessions still consume browser time. Understand how that is metered before you scale — see /pricing for current details.

The last point trips people up. A session that stays open for a human reviewer is still a running browser. If your mental model is "the agent finished, so billing stopped," a shared session will surprise you.

Where Remote Browser fits

Remote Browser is a hosted Chromium runtime for AI agents and browser-use workflows. It gives you CDP access, Playwright/Puppeteer/Selenium compatibility, a live viewer, persistent profiles, configurable browser settings, session isolation, and usage controls. Sharing is a consequence of those primitives rather than a bolt-on.

If you are coming from a local setup, the remote browser online guide walks through running real Chromium without managing Chrome yourself. If your interest is specifically in driving a session from code or an agent, the remote control browser post covers the control path. And the remote web browser overview is a good starting point if you are still mapping the category.

What Remote Browser does not do is promise fixed concurrency ceilings or a flat price. Those depend on your plan and workload. Check /pricing for the current model, and the /documentation for session and profile APIs.

Practical guidance

If you are deciding whether sharing belongs in your stack, work backward from the failure modes:

1. Start with persistence, not viewers. Persistent profiles solve the retry and re-auth problems that actually break agents. Live viewers are nice; state is load-bearing.
2. Treat a session as a resource with a lifecycle. Give it an ID, an owner, and an explicit end. Sessions that end when a process dies are hard to share.
3. Serialize writes, parallelize reads. If multiple clients touch one context, make sure only one writes at a time.
4. Scope viewer access. A live session URL is a credential. Treat it like one.
5. Measure browser time. Shared sessions consume it. Know your usage before you scale.

The honest summary: "Browserbase share" is a useful search because it points at a real problem — agents are stateful, and state has to move between runs, workers, and people. Whether you solve that with Browserbase, Remote Browser, or a self-hosted runtime, the requirements are the same. Pick the runtime whose session and profile model matches how your agents actually fail, then build the sharing around that.