TestDriver Options
Configure the TestDriver behavior with options that you give to theTestDriver() function:
Preview Mode
Control how test execution is visualized. Thepreview option determines where the live debugger view opens:
IDE Preview
For the best development experience, use
preview: "ide" with the TestDriver extension for VSCode or Cursor:
The legacy
headless: true option still works for backward compatibility and maps to preview: "none".Debug on Failure
Keep the sandbox alive when a test fails so you can reconnect and debug interactively. The sandbox ID is printed to the console along with instructions for reconnecting via MCP.IP Target
If self-hosting TestDriver, useip to specify the device IP. See Self-Hosting TestDriver for details.
Operating System
Set theos property to run tests on a specific operating system. Available options are linux (default) and windows.
Using Environment Variables
You can make the operating system configurable via environment variables. This requires adding code to read fromprocess.env in your test:
Dashcam Recording
Dashcam video recording is enabled by default. Disable it to skip recording:Automatic Screenshots
Screenshots are automatically captured before and after every command (click, type, find, assert, etc.) by default. Each screenshot filename includes the line number from your test file. Disable automatic screenshots:Caching
Element caching speeds up repeatedfind() and assert() calls. Enabled by default.
Redraw Detection
Redraw detection waits for the screen to stabilize before taking actions. Enabled by default.AI Configuration
Control how the AI model generates responses forfind() verification and assert() calls:
Environment Variables
Pass additional environment variables to the sandbox:Keepalive
By default, sandboxes stay alive for 60 seconds after disconnect. Customize this withkeepAlive:
0 to terminate immediately:
Connecting to an Existing Sandbox
Speed up test development by connecting to an existing sandbox instead of starting fresh each time. This lets you iterate quickly on failing steps without re-running the entire test from the beginning. Split your test into two files: one for known-good steps that set up the desired state, and another for work-in-progress steps you want to debug.known-good.test.mjs
work-in-progress.test.mjs
work-in-progress.test.mjs, you can re-run just that file to quickly iterate on the failing steps.

