What problem does this solve?
The cloud GSV target (platform cloudflare-worker) has no outbound network access through the shell — curl and DNS resolution are blocked. While fetch is available through the CodeMode sandbox (Cloudflare-native), it can only retrieve raw HTML/JS — it cannot render JavaScript-heavy SPAs, take screenshots, or interact with page DOM.
Currently, browser automation requires a connected browser extension target (a user's local browser). This means cloud-only deployments and autonomous agent workflows have no way to browse the web, render pages, or interact with web UIs without a human-operated browser.
What would you like to see?
Native browser rendering on the cloud GSV target using Cloudflare Browser Rendering (the remote Chromium service available on Cloudflare Workers Paid plans). This would give the cloud target the ability to:
- Render JavaScript-heavy SPAs and extract visible text content
- Take screenshots of pages
- Interact with page DOM (click, type, navigate)
- Run JavaScript in a real browser context
This could be exposed as a new capability on the gsv target (e.g. a browser or render command surface) or as a built-in browser target that doesn't require a user-side extension.
For agent harness use cases (predictable, deterministic, scalable autonomous task execution), having a cloud-native browser is critical — it enables web research, form submission, visual verification, and end-to-end testing workflows without any local hardware.
Anything else?
Cloudflare Browser Rendering is available on Workers Paid plans via the browserRendering binding: https://developers.cloudflare.com/browser-rendering/
The GSV manual already documents browser targets as a concept (devices-workplaces/targets-copy.md), but all current browser target capabilities assume a user-connected browser extension. A cloud-native browser target would be a significant capability unlock for autonomous agents.
You can see the gap today: asking an agent "what is at https://example.com" from the cloud target results in either a raw fetch of HTML (no rendering) or a failure. With Browser Rendering, the agent could render, screenshot, and interact with any web page entirely from the cloud.
What problem does this solve?
The cloud GSV target (platform
cloudflare-worker) has no outbound network access through the shell —curland DNS resolution are blocked. Whilefetchis available through the CodeMode sandbox (Cloudflare-native), it can only retrieve raw HTML/JS — it cannot render JavaScript-heavy SPAs, take screenshots, or interact with page DOM.Currently, browser automation requires a connected browser extension target (a user's local browser). This means cloud-only deployments and autonomous agent workflows have no way to browse the web, render pages, or interact with web UIs without a human-operated browser.
What would you like to see?
Native browser rendering on the cloud GSV target using Cloudflare Browser Rendering (the remote Chromium service available on Cloudflare Workers Paid plans). This would give the cloud target the ability to:
This could be exposed as a new capability on the
gsvtarget (e.g. abrowserorrendercommand surface) or as a built-in browser target that doesn't require a user-side extension.For agent harness use cases (predictable, deterministic, scalable autonomous task execution), having a cloud-native browser is critical — it enables web research, form submission, visual verification, and end-to-end testing workflows without any local hardware.
Anything else?
Cloudflare Browser Rendering is available on Workers Paid plans via the
browserRenderingbinding: https://developers.cloudflare.com/browser-rendering/The GSV manual already documents browser targets as a concept (
devices-workplaces/targets-copy.md), but all current browser target capabilities assume a user-connected browser extension. A cloud-native browser target would be a significant capability unlock for autonomous agents.You can see the gap today: asking an agent "what is at https://example.com" from the cloud target results in either a raw
fetchof HTML (no rendering) or a failure. With Browser Rendering, the agent could render, screenshot, and interact with any web page entirely from the cloud.