VM sandbox vs accessibility tree. Two axes, not alternatives.

No. They sit at different layers. A VM sandbox is an execution environment: where the agent process runs and which OS it sees. The accessibility tree is a grounding primitive: how the agent identifies what to click. You always have to pick both. Most articles treat them as a binary because Anthropic's reference Claude Computer Use container ships a Docker image with pixel-only grounding hardcoded inside; people see that one stack and assume sandbox means pixels. It does not. AX-based agents work unchanged inside any VM that exposes its own desktop session.

Anthropic's anthropic-quickstarts/computer-use-demo on GitHub ships a Dockerfile with a custom virtual display, a custom screenshot loop, and the computer_20251124 tool calling pixel coordinates. The whole stack is one artifact. When developers compare 'VM sandbox computer use' to a Playwright-style framework, they are really comparing two stacks that happen to differ on both axes at once: pixel-Docker versus AX-on-host. Then they ascribe the differences to one axis. The honest comparison fixes one axis at a time.

Yes. The repository ships vagrant/Vagrantfile out of the box. It provisions a stromweld/windows-10 box with 8192 MB RAM, 4 CPU cores, monitor-count 3, RDP enabled, OpenSSH installed, Scoop, Git, Python, NodeJS, Rust, and Chrome installed during provisioning. Port 8080 is forwarded for the MCP server and port 9222 for Chrome remote debugging. Set TERMINATOR_HEADLESS=1 inside the VM and the same terminator-mcp-agent npm package runs with a virtual session ID instead of the desktop session ID. The Windows UIA adapter is identical in both runs.

It is a string check inside is_headless_environment() at crates/terminator/src/platforms/windows/virtual_display.rs line 165. If the env var equals 'true' or '1', VirtualDisplayManager::initialize() sets session_id to 0 (a virtual session) and calls create_virtual_session(). Otherwise it sets session_id to 1 (the desktop session) and skips virtual setup. The AX walker that reads UIA roles, names, and bounds is downstream of both branches. The clustering pass, the MCP tool surface, and the click resolver do not know which branch was taken.

Three cases worth the cost. First, when the agent is going to run on a server you control and there is no user desktop to drive (overnight batch automation, CI tests against installed-software flows, anything that would otherwise need a 'dedicated Windows laptop'). Second, when isolation is a security requirement (testing a flow against installers you do not trust, untrusted scripts, third-party MCP servers whose blast radius you want bounded to a single VM). Third, when reproducibility matters more than fidelity (you want the same Windows build, same DPI, same locale, same default-app set every run). Outside those cases, running on the host is cheaper, faster, and uses the user's already-logged-in browser sessions.

When the goal is to act for the user inside their own apps. The user has Slack open with their team, Notion with their workspace, Cursor with their project, Chrome with twelve tabs and forty cookies. Spinning up a VM means losing all of that and re-authing inside the guest. The host run preserves the user's logged-in state, their installed extensions, their existing windows, and their actual screen. Terminator was built around this case, which is why the README leads with 'Uses your browser session, no need to relogin' and 'Doesn't take over your cursor or keyboard, runs in the background.' The accessibility-tree primitive is what makes 'in the background' possible; the host stack is what makes 'your browser session' possible.

Two reasons. First, pixel agents capture full-screen screenshots and inject mouse and keyboard events at OS level. Running that on the user's actual machine is hostile: every click steals focus, every screenshot includes the user's private windows, the user cannot use the machine while the agent runs. A VM gives the agent its own pixel buffer. Second, pixel grounding is portable across operating systems in a way that AX is not, so vendors ship one Linux Docker and call it cross-platform. The VM is not solving a computer-use problem there. It is solving an isolation and packaging problem. Pick a sandbox for the right reason.

No. By design. The Windows UIA APIs walk the session that the calling process lives in. A Terminator instance running inside a Vagrant guest sees the guest's Notepad, the guest's Chrome, the guest's Office. It does not see the host's apps. If you need the agent to drive user-installed software, run it on the host; if you need a clean slate every run, run it in the guest and install software during provisioning. The Vagrantfile in the repo does exactly that: Chrome, Rust, Python, NodeJS, and Git all get installed during 'vagrant up' so the guest is a fresh environment ready for AX-driven automation.

Those are hosted sandboxes (a VM somewhere with a remote-control protocol). The same orthogonality holds: you can run Terminator inside one of them by installing the npm package and setting TERMINATOR_HEADLESS=1, or you can use their built-in pixel-based tool. The choice between AX grounding and pixel grounding is independent of whether the sandbox is yours or hosted. Today these vendors ship pixel tools by default because their reference clients are pixel-only, not because their VMs cannot host an AX agent.

crates/terminator/src/platforms/windows/virtual_display.rs, function is_headless_environment, around line 165. The struct VirtualDisplayConfig (line 7) carries the resolution and refresh rate. VirtualDisplayManager::initialize (line 44) reads the env var, picks the session ID, and calls create_virtual_session. The default HeadlessConfig at line 187 wires use_virtual_display directly to the env-var check, which is why one variable is enough to switch the whole stack. None of those functions live inside the UIA adapter; they sit one layer above it.

The orthogonality argument does. The implementation is Windows-first today. The published npx terminator-mcp-agent binary targets Windows, and the Vagrantfile provisions Windows 10. macOS support is in the Rust core (the AX walker lives at crates/terminator/src/platforms/tree_search.rs) and on app.mediar.ai for users, but the headless-VM workflow in this article runs on the Windows side. On macOS the sandbox question is usually less urgent because the user is in front of a Mac running the agent on their host; on Windows the headless server case is common, which is why the VM tooling shipped there first.