#Agent web browsing

An agent can read web pages as part of its work: fetching documentation, checking an API reference, or reading a linked ticket. This browsing capability comes from a shared headless-Chrome service that runs alongside the platform, not from a browser installed inside the sandbox.

#How it works

The chrome-browser service runs a headless Chromium instance and exposes a Chrome DevTools Protocol endpoint on port 9222. When a sandbox starts, the platform injects the endpoint address as PLAYWRIGHT_MCP_CDP_ENDPOINT into the container's environment. The agent runtime picks up that variable and uses it to control the browser through Playwright's MCP bridge.

Because the browser is shared across sandboxes, the agent does not spin up or shut down its own browser process. It opens a page, reads what it needs, and closes the page when done.

#Availability

Browser access is on by default (agent_browser_enabled = true). If the chrome-browser service is not reachable when a sandbox starts, the environment variable is not injected and the agent has no browsing capability for that session.

In hardened mode, the chrome-browser service is always on the allowed list, so browsing continues to work even when outbound internet is restricted. Pages the agent can reach from a hardened sandbox are limited by the network the chrome-browser service itself can reach.

#What the agent can do

The agent can open any URL the browser service can reach, extract text and content from a page, and interact with pages through Playwright's tooling. It cannot access authenticated sessions you have open in your own browser; it browses as an anonymous client each time.

#Next steps

• Agent sandboxes: sandbox lifecycle and how the agent environment is set up.
• Hardened mode: how network controls affect what the agent can browse.