Read blocked pages or interact with them using Cloudflare Browser Run.
Installation
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Read blocked pages or interact with them using Cloudflare Browser Run.
Browser Run (Pi)
A real headless browser (Cloudflare Browser Run, headless Chrome) for public web pages that the built-in web fetch can't read or that you need to interact with. There are two surfaces, and picking the cheaper one is the point — a real browser session is the most expensive way to touch a page.
Reading a page: article/doc content, verifying rendered text/structure, pulling specific elements. The default when you just need to see what the page says.
Interactive
chrome-devtools via the mcp proxy (navigate_page, take_snapshot, take_screenshot, click, fill, evaluate_script, resize_page)
Expensive — opens a remote Chrome/CDP session
Driving a page: multi-step flows, clicking/typing, screenshots, viewport testing, e2e.
Both are Pro (advanced) only, and only when a Cloudflare API token with the Browser Rendering – Edit scope is configured. If the native browser_* tools are absent, Browser Run is not enabled for this session.
Decision order (cheapest that does the job)
Find pages on the web → web_search (pi-web-access), not Browser Run.
Static / normal page → use ctx_fetch_and_index when context-mode is available; otherwise use fetch_content (pi-web-access). Plain HTTP, no JS — fast and cheap. Context-mode is optional.
Raw HTTP / JSON API → curl.
Blocked or JS-only, but you only need to READ it → browser_markdown (clean Markdown — smallest, best for content), browser_content (rendered HTML/DOM), or browser_scrape (specific CSS selectors). One-shot, no session — prefer this over chrome-devtools whenever you don't need to interact. Don't retry curl on a page you already know needs JS.
You need to INTERACT — navigate a multi-step flow, click/fill, take a screenshot, test a viewport → drive chrome-devtools through the mcp proxy (see the pi-mcp-adapter skill for the proxy mechanics; list its tools, then call them). This is where e2e lives; see the browser-e2e skill.
Public URLs only. Never point Browser Run at internal hosts, localhost, private IPs, or anything requiring the user's session/credentials.
Read tools
Tool
Use it for
browser_markdown
The default. Returns the page as clean Markdown — best for reading article/doc content.
browser_content
Returns the fully-rendered HTML (after JS). Use when you need raw DOM/structure that Markdown drops.
browser_scrape
Returns text + HTML + attributes for specific CSS selectors. Use to pull structured bits without ingesting the whole page.
All three take url and an optional wait_until. For JS-heavy pages or SPAs, pass wait_until: "networkidle0" so content has rendered before capture.
Notes
Output is capped (~120k chars) to protect the context window; narrow with browser_scrape if a page is huge.
The read tools are one-shot fetches with no state between calls. For multi-step interactive automation (clicking through a flow, screenshots, viewport e2e), use the interactive chrome-devtools surface above — Pi has full parity with Claude here through the adapter.