Browserbase Release Notes

What's Changed

• [docs]: add docs for setDomainPolicy by @seanmcguire12 in #2289
• fix: silence AI SDK "system message in messages" warning in act/extract/observe by @shrey150 in #2359
• [STG-2510] fix: source eval browser skill from packages/cli browse SKILL.md by @shrey150 in #2334
• chore(evals): add sonnet-5, gpt-5.6, and grok pricing to braintrust UI publisher by @miguelg719 in #2318
• feat: warn and add opt-out flag for browse CLI .env auto-loading by @shrey150 in #2361
• chore(docs): Replace “LLM model” wording in Stagehand docs by @Kylejeong2 in #2366
• feat(evals): add OdysseysBench agent benchmark by @miguelg719 in #2275
• chore: cut stagehand-server-v3 catchup release by @shrey150 in #2367

Full Changelog: https://github.com/browserbase/stagehand/compare/@browserbasehq/[email protected]/v3.7.3

Original source

Stagehand 3.7.0 is live.

Use setDomainPolicy() to allowlist or blocklist the domains your agent can visit. Stagehand automatically closes any popup that tries to violate the policy.

await stagehand.context.setDomainPolicy({
  allowedDomains: [
    "www.browserbase.com"
  ],
});

Read the docs →

Plus:

• New CUA models: google/gemini-3.5-flash and the GPT-5.6 family (sol, luna, terra).

Fixes:

• CUA keypress actions now send key combinations as a single chord.
• Malformed UTF-16 snapshot text is repaired before it reaches model prompts.
• Removed a noisy AI SDK warning logged on every hybrid/DOM agent.execute() call.
• Fixed a crash when passing an MCP Client instance into agent({ integrations }).

Original source

Minor Changes

• #2283 871ca7e Thanks @seanmcguire12! - add context.setDomainPolicy({ allowedDomains: ["allowed.domain"] }) which allows users to define a set of domains that are accessible to stagehand
• #2274 f31980f Thanks @seanmcguire12! - add context.setDomainPolicy({blockedDomains: ["some.domain"]}) which allows users to define a list of domains that will be blocked by stagehand

Patch Changes

• #2305 cd1daad Thanks @shrey150! - Remove the noisy AI SDK "system message in messages" warning logged on every hybrid/DOM agent.execute() call.
• #2328 d287ff4 Thanks @miguelg719! - Allow modelName "auto" in the constructor and per-primitive model overrides when running through the Stagehand API
• #2294 3938590 Thanks @seanmcguire12! - automatically close popups that violate user defined domain policy
• #2298 892701a Thanks @seanmcguire12! - Fix CUA keypress actions to press key combinations as a single chord.
• #2345 21826c7 Thanks @monadoid! - Repair malformed UTF-16 snapshot text before it reaches model prompts.
• #2306 8dcef1b Thanks @seanmcguire12! - Use the screenshot provider's declared media type when sending CUA image payloads. The setScreenshotProvider callback now returns ScreenshotProviderResult ({ base64, mediaType }) instead of a bare base64 string.
• #2273 93a23d3 Thanks @miguelg719! - Add support for the new google/gemini-3.5-flash computer-use tools model
• #2278 022d68f Thanks @shrey150! - Fix TypeError: Converting circular structure to JSON when creating an agent with MCP integrations that include a Client instance (e.g. a local/stdio server from connectToMCPServer). The agent-creation log serialized the raw integrations array, and a live MCP Client is circular. It now logs a safe descriptor (URL strings kept, client instances summarized) so agent({ integrations: [client] }) works.
• #2288 bb5ffa6 Thanks @seanmcguire12! - clean up cdp session event handlers on target detach

Original source

Prepare the next browse release by versioning the package on main.

What this PR does:

• bumps packages/cli/package.json to 0.9.5
• updates the browse changelog
• consumes the pending browse changesets

After this PR merges, the Release workflow on main will publish
[email protected] from that exact commit using pnpm pack + npm publish --provenance.

Summary by cubic

Prepare the [email protected] release on main. Bumps the package version,
updates the changelog, and consumes the pending changeset so the Release
workflow can publish.

New Features

Add browse skills show to print the bundled skill and reference it
from --help.

Written for commit e01be37.

Summary will update on new commits.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Original source

Prepare the next browse release by versioning the package on main.

What this PR does:

• bumps packages/cli/package.json to 0.9.4
• updates the browse changelog
• consumes the pending browse changesets

After this PR merges, the Release workflow on main will publish
[email protected] from that exact commit using pnpm pack + npm publish --provenance.

Summary by cubic

Release [email protected], which makes browse snapshot print only the
accessibility tree by default to reduce noisy output. Includes version
bump and changelog update for publishing.

Migration

To get the previous full output (including xpathMap/urlMap), run
browse snapshot --full. Ref-based element commands are unchanged.

Written for commit 72cbd19.

Summary will update on new commits.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Original source

Prepare the next browse release by versioning the package on main.

What this PR does:

• bumps packages/cli/package.json to 0.9.3
• updates the browse changelog
• consumes the pending browse changesets

After this PR merges, the Release workflow on main will publish
[email protected] from that exact commit using pnpm pack + npm publish --provenance.

Summary by cubic

Prepare the [email protected] release by bumping the package version,
updating the changelog, and consuming the pending changeset. On merge,
the Release workflow on main will publish via pnpm pack + npm publish --provenance; this release also notes the new Docker image at
ghcr.io/browserbase/browse.

Written for commit 32f3a51.
Summary will update on new commits.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Original source

Describe a goal in plain language, get a browser agent you run with a single API call. No code to write, deploy, or maintain.

TL;DR: Browserbase Agents is a managed browser agent you create from a natural language prompt and run with one API call. Hand it a goal, get back structured results, and reuse the same agent across hundreds of sites without writing or maintaining a script per target. It runs on the same infrastructure behind 35M+ browser sessions a month, and it is generally available today on every plan.

If you run browser automations today, you already know the struggle. Every site you add is another script to write, every redesign is another script that breaks, and scaling past a handful of targets means standing up queues and workers before you have automated anything useful.

Browserbase Agents replaces all of that with a single browser agent, an AI system that navigates and acts on websites the way a person would, directed by natural language. Describe a goal, send one API call, and get a reusable agent that adapts when pages change and returns clean, structured results. And unlike the scripts it replaces, it improves over time: every agent can be tuned to run faster and more reliably the more you use it. It all runs on the same platform behind 35M+ browser sessions a month for teams like Ramp, Shopify, and Lovable.

What is a Browserbase Agent?

A Browserbase Agent is a browser agent you create by describing a goal, not by writing selectors. Under the hood it runs on the full platform, with browsers at the center: real headless browsers handle the interaction, Agent Identity gets the agent past anti-bot systems and authentication walls, and Search and Fetch pull web context when a full session would be overkill. Every step is recorded for you to inspect. The web was never built for agents, so making one reliable takes a real harness underneath.

The difference from building it yourself is the deployment story. With our SDK, Stagehand, you wire up and host the agent loop in your own infrastructure. With Browserbase Agents, there is nothing to host. You describe the goal, we run the agent, you get the result back.

How it works

There is no framework to learn and no code to deploy. You write the goal the way you would brief a teammate, in plain language, and send it with a single API call. The agent runs on our infrastructure, decides how to navigate each site for itself (how much autonomy an agent should have is a design question in its own right), and adapts to the layout differences and per-site quirks that break hand-written scripts.

Runs are asynchronous, so a long job never blocks your request. You start a run and check back on it when it is done. And because every run takes a result schema you define, what comes back is structured, typed data shaped exactly the way you asked, ready to drop straight into your system with no parsing or cleanup.

Create the agent once and point it at the next portal, then the one after that. One agent covers the long tail that used to take one script per site.

See every run

A managed agent is only useful if you can trust it, and trust comes from being able to watch it work. Every run is a real browser session with full observability built in: a live view of the browser as the agent acts, Session Replay to scrub back through any completed run, and traces across both model calls and tool calls so you can see exactly why the agent did what it did, alongside a per-run cost breakdown.

When an agent does something strange, you do not guess. You open the run and watch the frames it saw.

Agents that get better over time

Shipping an agent is the start, not the end. Optimize takes a working agent and tunes it three ways:

• Make faster: trim the steps a run takes so it finishes quicker and costs less
• Debug: investigate a run that went wrong and correct the behavior behind it
• Refactor: restructure the agent as the task grows, so it stays reliable instead of drifting

The agent you ship in week one is not the agent you are stuck with. It improves as you run it, the first step toward agents that get better largely on their own, which is where we think this is all heading (more on that in Autobrowse).

What you can build

Browserbase Agents fits the work that was always too varied to script cleanly and too large to script one site at a time:

• Monitoring: track pricing and competitor changes across dynamic, protected sites
• KYC and KYB across customer and business portals that all look different
• Government and real estate records: pull tax documents and property records across 1,500+ county and state sites
• Document retrieval: find SOC 2 reports, authorization forms, and transaction documents wherever they live
• Automated QA for teams scaling their product development with coding agents

The common thread is the long tail. One agent covers 200 portals instead of 200 scripts, and it keeps working when those portals change.

Get started

Browserbase Agents is generally available today on every plan, with included runs to start building right away:

Plan Agent runs included Free 3 per month Developer 15 per month Startup 50 per month Enterprise Custom

Describe your first agent and run it in a single call. Read the docs to get started.

The web was built for humans. Now your agents can use it like one.

Original source

Prepare the next browse release by versioning the package on main.

What this PR does:

• bumps packages/cli/package.json to 0.9.1
• updates the browse changelog
• consumes the pending browse changesets

After this PR merges, the Release workflow on main will publish [email protected] from that exact commit using pnpm pack + npm publish --provenance.

Summary by cubic

Prepare [email protected] by bumping the CLI version and updating the changelog; merging will trigger the Release workflow to publish.

New Features

Attribute CLI-driven Browserbase usage to an anonymous install. Sessions stamp install_id and cli_version in userMetadata. Cloud Search/Fetch send x-bb-client and x-bb-install-id. Best-effort and non-blocking.

Written for commit f2eca53.

Summary will update on new commits.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Original source

Minor Changes

#2246 303ab2c Thanks @shrey150! - browse screenshot now writes a file by default instead of printing base64 to stdout. Bare invocations save to screenshot-<yyyymmdd-hhmmss>.<type> in the current directory (with a collision counter instead of overwriting) and print { "saved": "<path>" }. A new --base64 flag preserves the legacy behavior of printing { "base64": "..." } to stdout; it is mutually exclusive with --path. --path behavior is unchanged.

Note for scripts that parsed the bare-invocation base64 output: pass --base64 to keep the old stdout contract.

Patch Changes

#2250 8b83bb7 Thanks @shrey150! - Fix browse skills add on Windows and bound the unbounded installer stages.

Quote the npx command and arguments when spawning through cmd.exe (shell: true for .cmd/.bat shims), so the default C:\Program Files\nodejs\npx.cmd path and install paths with spaces (e.g. C:\Users\First Last...) no longer split at the space and fail with "'C:\Program' is not recognized".

Kill the npx skills add child after a 180s deadline (SIGTERM, then SIGKILL) and fail with a clear message and a distinct skill_install_timeout telemetry result code instead of hanging forever.

Bound the catalog and skill-file fetches with a 10s abort timeout, preserving the existing catalog-unavailable fallback semantics when a fetch hangs.

Original source

Stagehand 3.6.0 is live.

With WebMCP support, a page can expose typed, first-party tools directly to your agent — so Stagehand calls those tools instead of inferring actions from the DOM. Discover what a page offers with page.listWebMCPTools() and run one with page.invokeWebMCPTool().

const page = stagehand.context.pages()[0];
await page.goto("https://example.com");
// Discover the tools the page exposes
const tools = await page.listWebMCPTools();
// Invoke one directly
const result = await page.invokeWebMCPTool("searchFlights", {origin: "SFO", destination: "JFK"}, {frameId: tools[0].frameId});

Read the WebMCP docs →

Plus:

• Azure OpenAI auth via Microsoft Entra ID.
• claude-fable-5 support, with adaptive thinking and the new xhigh effort.
• Smarter act caching — URLs that differ only in query-param order now hit the cache.

Fixes:

• Shadow-root XPath resolution so deterministic actions can target elements inside web components.
• Security and dependency updates.

Original source

Minor Changes

• #2178 c49a3fc Thanks @seanmcguire12! - add support for WebMCP

Patch Changes

• #2217 147e310 Thanks @monadoid! - Add Azure OpenAI Microsoft Entra ID model auth support.
• #2231 cf3603d Thanks @miguelg719! - Add claude-fable-5 support: native structured outputs via the @ai-sdk/anthropic bump, adaptive thinking (including the new "xhigh" effort) on the agent path, the API's built-in server-side refusal fallback to claude-opus-4-8, and auto tool choice for the final done call on models that reject forced tool use.
• #2233 8d7d414 Thanks @seanmcguire12! - Normalize URLs in ActCache key derivation by sorting query parameters before hashing. Semantically equivalent URLs that differ only in parameter order (e.g. ?utm_source=email&id=42 vs ?id=42&utm_source=email) now hit the cache instead of silently missing. Fragments and duplicate keys are preserved.
• #2229 fd42e65 Thanks @seanmcguire12! - launch local browser with --enable-features=WebMCPTesting,DevToolsWebMCPSupport by default
• #2220 a64c6b7 Thanks @monadoid! - Fix Stagehand-generated shadow-root XPath resolution so deterministic actions can target elements inside web components.
• #2132 ed3e566 Thanks @miguelg719! - Add canonical verifier evidence normalization for screenshots and text signals without requiring image dependencies in core installs.
• #2133 840aac8 Thanks @miguelg719! - Add the rubric-based verifier engine with normalized public rubric output and bounded failure-step parsing.

Original source