A browser for AI agents: run Chrome in a disposable sandbox

Sooner or later an agent needs a browser. It has to check the page it just deployed, fill in a form on a staging app, pull data from a site with no API, or, for a computer-use model, look at a screen and decide where to click. The quickest option is to let it drive the Chrome on your laptop. That works until the agent reads a page telling it to do something you didn't ask for, while it's signed in as you.

The other option is a real Chrome in a disposable Linux VM that the agent can use freely and that you throw away afterwards. Below you'll find when to run it headless or headed, how your code connects to it, how a person can watch or step in, and when a managed browser is the better choice. The full recipe, with every unit file and script, is on the Chrome and Chromium docs page.

Why not your laptop or a shared server

An agent's browser reads untrusted input on every page load. Anthropic's computer use documentation says it plainly: instructions on web pages or in images can override your instructions, and its first recommended precaution is a dedicated virtual machine or container with minimal privileges. The second is keeping sensitive data, like account logins, away from the model.

Your laptop meets neither. Its browser profile holds your cookies and saved passwords, the machine can reach localhost and your internal network, and the agent's downloads land next to your files.

A long-lived browser server shared by several agents or jobs has a subtler problem: state carries over. Cookies, local storage, open tabs and a half-finished login from one run are there for the next one. When one job crashes Chrome, the others go down with it. And you can't reproduce a failure, because the browser you debug is no longer in the state the agent saw.

A disposable VM gets rid of most of this. Each Tenki Sandbox session is a hardware-isolated VM with its own kernel, and its disk and memory are wiped when the session ends. Every run starts from the same prepared state, and nothing in the browser profile outlives the task unless you save it on purpose. Because you run as a non-root user in a full VM, Chrome's own process sandbox works too, so you can leave out the --no-sandbox flag that root-in-a-container setups tend to need.

A sandbox doesn't filter what the browser can reach, though. A session's networking settings are inbound and outbound, each on or off, set when you create it. A browsing agent needs outbound access, so if you want a domain allowlist like the one Anthropic recommends, you have to add it yourself, for example with a proxy inside the VM.

Headless or headed

Chrome's new headless mode runs the same browser code as regular Chrome. It creates windows without displaying them, and the old separate implementation now ships as chrome-headless-shell. So headless is the real browser, and it covers most agent work: scraping, end-to-end tests, screenshots, and agents that read the DOM or the accessibility tree. It needs nothing besides Chrome itself.

Headed means a virtual display (Xvfb), a VNC server on it (x11vnc), and a web client for that VNC server (noVNC). You need it when a person has to see the browser: to debug a flow, to supervise a computer-use agent while it works, or to take over when it gets stuck. The docs also recommend it for sites that behave differently when there is no real window.

A computer-use model doesn't need a headed browser to see the page. page.screenshot() works headless and gives the model the same pixels, so the reason to go headed is a person who needs to watch.

Bake Chrome in once

Installing Chrome is the only slow step, so do it once and keep the result. Start a builder session, run the install script from the docs, take a snapshot, and throw the builder away:

tenki sandbox create --name chrome-builder --disk-size-gb 10
tenki sandbox exec -c "$(cat install-chrome.sh)"
tenki sandbox snapshot create --name chrome-stable
tenki sandbox terminate

Every session you start with --snapshot <snapshot-id> then has google-chrome on its PATH. If you would rather keep the recipe in a reviewed file, the same install fits in a single run step of a template, and sessions start from --image <ref> instead.

Snapshots matter even more for the headed setup. A snapshot captures memory as well as disk, so if you take it after Xvfb, Chrome, x11vnc, noVNC and nginx are all up, a session restored from it doesn't boot anything. The whole stack resumes already running, with the browser open. Check that every service is active before you snapshot, because the snapshot keeps whatever state they are in.

Connect over CDP

Your agent's code runs outside the browser VM and drives it through the Chrome DevTools Protocol. Chrome runs as a systemd service with --remote-debugging-port=9222. It only listens on loopback, which is the right default, because anyone who can reach that port controls the browser.

To reach it from outside, the docs put a small nginx site on port 9333. It rewrites the Host header, which Chrome checks, and passes WebSocket upgrades through. Then you expose the port:

tenki sandbox create --name chrome-cdp --snapshot <snapshot-id> --sticky
tenki sandbox expose --port 9333 --ttl 8h

expose returns an HTTPS preview URL that carries the CDP WebSocket as-is. Chrome advertises its endpoint as ws://127.0.0.1:9222/... because that's the address it sees, so swap that origin for the preview URL and attach with Playwright:

import { chromium } from "playwright-core";

const res = await fetch(`${cdpUrl}/json/version`);
const { webSocketDebuggerUrl } = (await res.json()) as { webSocketDebuggerUrl: string };
const endpoint = webSocketDebuggerUrl.replace("ws://127.0.0.1:9222", cdpUrl.replace(/^https:/, "wss:"));

const browser = await chromium.connectOverCDP(endpoint);

Puppeteer takes the same endpoint:

import puppeteer from "puppeteer-core";

const browser = await puppeteer.connect({ browserWSEndpoint: endpoint });

Two things to know about this setup. Playwright's docs call a CDP connection significantly lower fidelity than its own protocol, and it only works with Chromium-based browsers. That's the cost of attaching to a Chrome that Playwright didn't launch. Disconnecting also leaves the browser alone: browser.close() on a CDP connection only drops the connection, and Puppeteer's disconnect() leaves the process running. Tabs, cookies and the profile stay in the VM. That suits short-lived callers such as serverless functions or queue workers, which can attach, do one bounded task and leave, while the session holds the browser.

Don't hand the agent that whole API. Give it a few verbs (look, open, click, type, scroll, read text) and keep session lifecycle, port exposure and snapshot deletion in the code that runs the agent. The docs have a tool surface you can start from.

Let a human watch or take over

In the headed setup there is one Chrome behind two preview URLs: 9333 for CDP clients and 6080 for people. Open the noVNC page and you see the agent's browser while it works:

tenki sandbox expose --port 6080 --ttl 8h
tenki sandbox expose --port 9333 --ttl 8h

The viewer is at <6080 preview URL>/vnc.html?autoconnect=true&reconnect=true&resize=scale&path=websockify.

The view works in both directions. Whatever Playwright does shows up in the noVNC tab as it happens, and whatever a person clicks or types there shows up in Playwright's next screenshot. So a human can handle the step the agent shouldn't, such as a login or an MFA prompt, or confirm a consequential action before the agent takes it, and then hand control back without restarting anything.

That URL is the whole desktop with keyboard and mouse control, and VNC runs without a password behind it. Treat it, and the CDP URL, as a bearer secret: keep the TTL no longer than the work needs, keep it out of shared channels, and run tenki sandbox unexpose when you're done.

Things that trip people up

• A browser that agents connect to over hours shouldn't hit the default maximum duration, so create the session with --sticky. It then runs until you terminate it, which means you have to terminate it yourself.
• Exposures belong to the session, not the snapshot, so you have to expose the ports again after every restore.
• Save output under /home/tenki. The file APIs can't read /tmp, and it's cleared when a session pauses.
• You pay while the browser runs: sessions bill per second, and snapshots count against workspace storage. See pricing.

When to use a managed browser instead

Self-hosted Chrome in a sandbox works well when you control the target: your own apps, preview deploys, staging and test environments, internal tools, and public pages that don't fight automation. You get the exact browser build you installed, a profile that disappears with the session, and a VNC view you set up yourself.

It's the wrong tool when the target sites use bot detection, or when your agents need persistent logged-in identities across many sessions. A fresh Chrome in a VM looks like what it is, and a disposable profile is the opposite of a long-lived login. That's where a managed browser like Anchor fits: the agent still runs in the sandbox, and the browser runs on the provider's side of the CDP connection. Connect a sandboxed AI agent to Anchor Browser over CDP covers that setup.

Next step

Start with the headless path in the Chrome and Chromium guide: bake the snapshot, run one --dump-dom, then attach Playwright over the preview URL. Add the display stack once someone needs to watch. The guide also covers Chromium, Brave and Edge, and cleanup.