Browser Run: A Purpose-Built Browser for AI Agents

AI agents need more than just an API to work on the web — they need a full browser they can drive, observe, and hand off to a human when things get complicated. Cloudflare is renaming its Browser Rendering product to Browser Run to reflect that broader mission, and the new name comes with several capabilities aimed squarely at agentic workflows.

The product now supports real-time session observation, human intervention mid-task, direct protocol access for maximum control, and higher concurrency limits. Here’s what changed.

Live View and Human Oversight

When an automation fails, the most common problem is visibility — you simply don’t know what went wrong. Browser Run now addresses this in two complementary ways.

Live View streams an active browser session in real time, showing the page, DOM, console output, and network requests as they happen. You can spot a missing button, an unexpected login wall, or a CAPTCHA the moment it appears. Access it from code by grabbing the session_id and opening the returned devtoolsFrontendURL in Chrome, or from the Cloudflare dashboard’s new Live Sessions tab.

For sessions you can’t watch live, Session Recordings capture DOM changes, mouse and keyboard events, and page navigation as structured JSON. Launch a browser with recording:true, and after the session closes you can replay it in the dashboard or via API using the rrweb-player. DOM state and console inspection at any point during a recording are planned next.

When an agent hits a snag it can’t resolve, it no longer has to fail outright. The new Human in the Loop feature lets the agent pause and hand control to a person — for a login page, for instance — who resolves the issue and returns control to the agent.

Direct Protocol Access

Under the hood, Browser Run has always operated through the Chrome DevTools Protocol. What’s new is that CDP is now exposed directly as an endpoint. Agent frameworks that already speak CDP natively can connect without adapters, and existing automation scripts written against self-hosted Chrome can be pointed at Browser Run with a one-line WebSocket URL change.

Direct CDP access gives agents the most granular control possible, including capabilities not available through higher-level libraries like Puppeteer or Playwright — JavaScript debugging being one example. It also opens the door to more token-efficient browser control, since raw CDP messages can be passed straight to a model without wrapping layers. Additionally, the endpoint removes the need to write a Cloudflare Worker to use the service; connections can come from any language or environment.

The CDP endpoint also makes Browser Run usable as a remote browser for MCP clients. Claude Desktop, Cursor, Codex, and OpenCode can now drive Browser Run through the chrome-devtools-mcp package, giving AI coding assistants full DevTools power for automation and debugging.

WebMCP Support

Websites are built for humans, which makes them unreliable terrain for agents that must infer UI structure from pixels. WebMCP, a browser API from the Chrome team shipping in Chromium 146+, lets sites declare their capabilities explicitly.

Two APIs make this work: navigator.modelContext lets websites register tools, while navigator.modelContextTesting lets agents discover and execute those tools. A travel site, for instance, can declare a search_flights tool with origin, destination, and date parameters — an agent calls it directly instead of engaging in slow screenshot-and-click loops. Discovery happens on the page itself, avoiding the need to preload servers for the long tail of the web.

To try WebMCP before it reaches stable Chrome, Browser Run maintains an experimental pool running beta builds. A new Wrangler command for creating sessions in that pool is available, alongside the recently shipped Wrangler browser commands for managing sessions from the terminal.

Existing Automation Paths

Beyond CDP, existing automation approaches continue to work. Puppeteer, Playwright, and Stagehand all run through Browser Run for full browser control, and the Quick Action REST endpoints cover simple tasks — screenshots, PDFs, and markdown extraction — with single calls.

A /crawl endpoint, added recently, crawls entire sites from one request. Provide a starting URL and pages are discovered and scraped automatically, returned as HTML, Markdown, or structured JSON. Parameters control crawl depth and scope, skip unchanged pages, and include or exclude specific paths.

The crawler is designed to be a good citizen: it respects robots.txt and AI Crawl Control, carries a cryptographically signed agent ID via Web Bot Auth, uses a non-customizable User-Agent, and will not bypass Cloudflare bot protections or CAPTCHAs. Site owners retain control over whether their content gets crawled.

Dashboard Redesign and Limits

The dashboard has been reworked so that every request is visible. A new Runs tab shows all browser sessions plus quick actions like PDF, screenshot, and crawl requests — previously only session logs appeared. You can filter by endpoint and inspect target URLs, status, and duration for each request.

Concurrency limits have also been raised. Browser Run now supports 120 concurrent browser sessions, up from 30, for larger-scale agent workloads.

Stepping in when the agent gets stuck

Automation isn't infallible. When an agent hits a wall—a login prompt, a CAPTCHA, an unexpected modal—Browser Run lets a human take over the live session directly. This Human in the Loop workflow allows you to click, type, navigate, enter credentials, or submit forms on the page, then hand control back to the automation. No need to kill the session and start over.

Currently, intervention happens by opening the Live View URL for an active session. A handoff flow is on the roadmap: the agent will be able to signal that it needs assistance, notify a human to step in, and then resume control once the issue is cleared.

Raising the ceiling for concurrent work

Demand for higher throughput has driven a significant increase in limits. The default concurrent browser limit has been quadrupled from 30 to 120. Sessions pull from a global pool of warm instances, so there's no cold-start latency when a browser spins up. Quick Actions limits were also raised in March to 10 requests per second. Higher limits are available on request for workloads that need them.

On the roadmap

  • Human in the Loop Handoff: live intervention exists today; the agent will soon be able to request help, letting you build notification flows that alert a human when intervention is needed.
  • Session Recordings Inspection: timeline scrubbing and replay are already available. DOM state and console output inspection are coming.
  • Traces and Browser Logs: debugging information—console logs, network requests, timing data—without instrumenting your code.
  • Screenshot, PDF, and markdown from Workers: the REST API’s simple tasks are arriving in Workers Bindings, so env.BROWSER.screenshot() works directly without API tokens.

Availability

Browser Run is live today on both Workers Free and Workers Paid plans. The features shipped in this release—Live View, Human in the Loop, Session Recordings, and the higher concurrency limits—are ready to use now. Existing Browser Rendering users will find everything works the same, just under the new name and with more capabilities. The documentation has the full details.