signup-checkout-test is the template for that, and everything about how it is configured follows from the fact that it writes.
What it does
Drives the flow you name from a start URL, screenshots every step, and files a GitHub issue when a step fails. Its defaults are Safe writes,safe execution mode, a 15-minute timeout, and an allowlist covering the target site and api.github.com.
Point it at staging, and prove it
This template’s own sample input is deliberately marked not demo-safe. It walks a checkout with a synthetic test card, and Obol will not pretend that a card-shaped flow against an arbitrary target is a sandbox. Use a staging environment, and narrow the allowlist to it so the Worker cannot reach production even if the model is confused about which site it is on.Shadow mode
Browser and desktop test mode is shadow mode: the Worker reports the action it would take rather than committing it. That is the mode to run a new flow Worker in first — it produces the same output structure as production, so the deliverables tell you whether the walkthrough is right before any of it lands.Two kinds of thing a browser Worker does
The distinction matters enough that the interface shows it, and no execution mode erases it.
Filing the issue is the first. Clicking through checkout is the second. A screenshot of an order confirmation is evidence that a page rendered that way; it is not proof that an order exists in the vendor’s system. Where an action’s effect cannot be established from observations, the run stops with
ambiguous_effect_requires_review rather than guessing — and a Worker’s default of zero ambiguous-write retries means nobody retries a write whose outcome is unknown.
autonomous mode asks for fewer approvals and still enforces every limit. It does not lift the restriction on high-impact arbitrary UI actions; that restriction is a semantic boundary, not a preference.