Cloudflare Browser Run for agents
Browser Run is useful because real agents need browser control, live view, session replay, CDP access, and human handoff when the web gets messy.
When an agent’s browser automation fails, most teams have no idea why — because they never built the debugging surface a browser-driving agent actually needs.
Source
Browser Run: give your agents a browser
By: Cloudflare
Published: Apr 15 2026
Type: Product announcement
This matters because agents that work on the web need more than a headless browser. They need real-time observability, session replay, and a way to hand control to a human when things get messy. Browser Run is Cloudflare’s answer to that full stack of requirements.
What agents need from a browser and what Browser Run provides
Agents that browse the web have five needs: on-demand browsers, ways to control them, observability into what’s happening, human intervention when automation fails, and scale. Browser Run (renamed from Browser Rendering, because the old name undersold it) addresses each one.
Getting a browser is straightforward — agents spin up headless Chrome instances on Cloudflare’s global network, on demand, no infrastructure to manage. Sessions open near users for low latency and scale up or down as needed. The default concurrent browser limit jumped from 30 to 120, with warm instances that avoid cold starts.
Control is where things get interesting. Browser Run already supported Puppeteer, Playwright, and Quick Actions (simple endpoints for screenshots, PDFs, and markdown extraction). The new additions are the Chrome DevTools Protocol (CDP) endpoint, MCP client support, and WebMCP.
CDP is the low-level protocol underneath Puppeteer and Playwright. Exposing it directly means agents get maximum browser control — including capabilities like JavaScript debugging that aren’t available through higher-level libraries. Existing CDP scripts work on Browser Run with a one-line config change: swap your local WebSocket URL for the Cloudflare endpoint. Because you’re working with raw CDP messages, you can also pass them directly to models for more token-efficient browser control. The CDP endpoint also makes Browser Run accessible from any language and any environment, not just Workers.
MCP client support builds on CDP. AI coding tools like Claude Desktop, Cursor, and OpenCode can now use Browser Run as their remote browser through the chrome-devtools-mcp package from the Chrome DevTools team. Configure it once and your coding assistant gets full Chrome DevTools power against a remote browser.
WebMCP addresses a deeper problem: the internet was built for humans. An agent visiting a travel site today has to look at the page, figure out the UI, and loop through slow screenshot-analyze-click cycles. WebMCP (a new browser API from the Chrome team in Chromium 146+) lets websites declare what actions are available. A travel site registers a search_flights tool with origin, destination, and date parameters. The agent calls it directly. Tools are discovered on the page rather than preloaded, which matters for the long tail of the web where preloading an MCP server for every possible site would bloat the context window.
Observability comes through two features. Live View lets you watch an agent’s browser session in real time — the rendered page, DOM, console, and network requests. When something goes wrong (missing button, surprise login page, CAPTCHA), you catch it immediately. Session Recordings capture DOM changes, mouse and keyboard events, and page navigation as structured JSON so you can replay any session after it ends. Enable recordings by passing recording: true when launching a browser.
Human in the Loop is what keeps agents useful instead of stuck. When automation hits a wall — a login page, an unexpected edge case, a CAPTCHA — a human opens the Live View URL, takes direct control (click, type, navigate, enter credentials), resolves the issue, and hands back to the agent. The coming handoff flow will let the agent signal when it needs help and notify a human automatically.
Cloudflare also shipped a /crawl endpoint that handles site-wide crawling from a single API call. It discovers pages automatically, returns content in HTML, Markdown, or structured JSON, and respects robots.txt and AI Crawl Control by design — it’s a signed agent with a cryptographically signed bot ID and a non-customisable User-Agent.
My take
The piece that stands out is WebMCP. Most browser automation for agents treats the web as a visual surface to screenshot and parse. WebMCP treats it as a structured API surface that websites can opt into. If adoption grows, it fundamentally changes the reliability equation — agents stop guessing at UI and start calling declared tools. The practical question is adoption: until most sites implement WebMCP, agents still need the screenshot-analyze-click fallback, and Browser Run supporting both paths is what makes it genuinely useful today rather than only useful in a future that may or may not arrive.
Where this is useful
- When building any agent that browses the web — the combination of CDP, Live View, and session recordings gives you the debugging surface that “agent failed on step 3” error messages can’t provide.
- When your automation needs to handle login pages, CAPTCHAs, or other human-only steps — Human in the Loop keeps the agent workflow running instead of crashing.
- When you’re already running CDP scripts against self-hosted Chrome and want to stop managing browser infrastructure — one-line config change to migrate.
Apply this: If your agent browses the web without session recordings enabled, turn them on now. The first failed automation you can actually replay will save hours of guesswork.
What I want to remember
Remember: Browser automation for agents needs three layers: control (CDP/Puppeteer/Playwright), observability (Live View + recordings), and a human escape hatch. Without all three, debugging agent web tasks is guesswork.