Skip to main content
If your agent fetches a web page, scrapes data, or previews a website it just generated, the sandbox is where that happens. Each browser session runs in its own microVM — no cross-tenant cookie leakage, no shared Chromium profile, no “oops, the last agent left a modal open.”

Headless browser — Playwright

Real-world uses

  • Research agents that gather links + screenshots for a report.
  • Accessibility audits — launch Chromium, inject axe-core, return violations.
  • Form-filling bots for routine admin work on sites without an API (expense reports, government portals, etc.).
  • “Visual diff” on generated UIs — screenshot before and after a change, pipe both to a vision model.
First-time playwright install downloads ~120 MB. Do it in the first agent turn and keep the sandbox alive for the session so subsequent turns skip the download.

Boot a Next.js dev server, screenshot the result

This is the pattern for v0.dev-style “AI-generated websites.” The agent writes React files, the sandbox runs next dev, Playwright takes a screenshot so the user can see what the agent built.

Why isolation matters

  • Cookies + localStorage. Fresh per sandbox. Nothing to leak between customers.
  • Downloaded files. /tmp is the sandbox’s, not yours. When the sandbox dies, so do the downloads.
  • Long-running headless Chromium. Chromium likes to eat RAM and sometimes crash. The host is never affected; your box dies, your box respawns, the user doesn’t see it.

Pitfalls

  • Headless Chromium is memory-hungry. 1 GB free-tier RAM is tight — expect OOMs on heavy pages. Pro (4 GB) is the happy place.
  • page.wait_for_load_state('networkidle') is more reliable than time.sleep(3). Use it for agent-generated pages where you don’t know how long hydration takes.
  • Don’t pip install playwright per turn. Install once at sandbox start; subsequent turns reuse the venv.