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.