Project
CLI
Every danwo command and its options.
danwo init
danwo test
danwo matrix tests/buy-credits.danwo.ts
danwo serve --opendanwo <command>; every command takes --help.
test
command
danwo test [patterns...]run test files in worker processes
| Member | Description |
|---|---|
patterns | file paths or substrings narrowing the config's testMatch |
--lint | run the integration lint over provider calls and webhooks (default: on) |
--no-lint | skip the integration lint |
--reporter <names...> | reporters besides the console's list: github (a check run, a pull request comment and the job summary in GitHub Actions), junit (.danwo/junit.xml) |
--no-pr-comment | github reporter: no pull request comment, only the check run |
-w, --workers <n> | worker processes |
--split-files | hand workers single tests of the files whose tests share nothing (no beforeAll or afterAll) |
-r, --retries <n> | retries per test |
-g, --grep <regexp> | only tests whose full title matches |
--last-failed | only the tests that failed in the latest run; merges into it |
--changed | only the tests the changed files can affect (see danwo impact) |
--since <ref> | what --changed compares with (default: HEAD, uncommitted changes) |
--shard <i/n> | this machine's share of the test files, e.g. 2/4 |
--max-failures <n> | start no new test file once this many tests failed |
--max-duration <time> | start no new test file once the run has taken this long, e.g. 20m (files left out fail the run) |
--ci | CI defaults even without the CI variable: 1 retry, read-only cache, no .only |
--replay-only | replay recorded agent steps and call no model: a step with no recording that replays fails |
--list | print the picked tests as JSON (id, file) instead of running them |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
on-failure | always | off | flight recorder: keep what runs did (default: config, else always) |
retain-on-failure | on | off | video in kept records: retain-on-failure keeps failed runs' (default: config, else on) |
--keep-runs <n> | how many of the newest runs keep their recordings (default: config, else 50) |
-u, --update-snapshots | rewrite every toHaveScreenshot baseline |
matrix
command
danwo matrix <file>record a clean run of one test, then replay it once per planned fault
| Member | Description |
|---|---|
file | test file |
--lint | run the integration lint over provider calls and webhooks (default: on) |
--no-lint | skip the integration lint |
--reporter <names...> | reporters besides the console's list: github (a check run, a pull request comment and the job summary in GitHub Actions), junit (.danwo/junit.xml) |
--no-pr-comment | github reporter: no pull request comment, only the check run |
-g, --grep <regexp> | selects the test when the file has several |
-f, --faults <regexp> | only the planned faults whose labels match |
-w, --workers <n> | worker processes (default: one per core, at most 8) |
--max-failures <n> | start no new run once this many failed |
--shuffle <seed> | run the faulted runs in a shuffled order |
--plan | run the clean run, print the planned faults and how long they would take, and stop |
--budget <n> | at most this many faulted runs (default: config, else 40) |
--all | every fault on the test's body, background work included, with no budget |
--thorough | every fault kind on each call, not only the most telling ones |
--every-occurrence | faults on every repeat of a route or statement, not only its first |
--include-setup | fault the test's setup too: its saved session signing in, fixtures and beforeEach |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
on-failure | always | off | flight recorder: keep what runs did (default: config, else always) |
retain-on-failure | on | off | video in kept records: retain-on-failure keeps failed runs' (default: config, else on) |
--keep-runs <n> | how many of the newest runs keep their recordings (default: config, else 50) |
-u, --update-snapshots | rewrite every toHaveScreenshot baseline |
merge-reports
command
danwo merge-reports [files...]join the results of a split run (danwo test --shard i/n) into one report
| Member | Description |
|---|---|
files | results files (default: .danwo/results/shard-*.json) |
--reporter <names...> | reporters besides the console's list: github (a check run, a pull request comment and the job summary in GitHub Actions), junit (.danwo/junit.xml) |
--no-pr-comment | github reporter: no pull request comment, only the check run |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
impact
command
danwo impact <files...>which tests a change to these files selects for danwo test --changed, and why
| Member | Description |
|---|---|
files | changed files |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
mcp
command
danwo mcpserve this project to coding agents over MCP (stdio)
| Member | Description |
|---|---|
-c, --config <path> | config file (default: nearest danwo.config.ts) |
default 4 | live sessions open at once |
init
command
danwo initset danwo up in this project: the engine, the model for agent steps, the providers to emulate and the coding agents to teach; writes danwo.config.ts, an example test and a test:danwo script, and installs what they import. Asks in a terminal; with --yes or no terminal it takes the flags and what it detects
| Member | Description |
|---|---|
-y, --yes | ask nothing: the flags, and the detected defaults for the rest |
web | mobile | both | none | what tests drive |
gateway | anthropic | openai | google | openrouter | openai-compatible | none | where agent steps get their model |
--model <id> | the model id, e.g. anthropic/claude-sonnet-5 on the AI Gateway |
--base-url <url> | an OpenAI-compatible server's URL (--model-source openai-compatible) |
--key-env <name> | the variable holding that server's key, when it takes one |
--providers <list> | providers to emulate, comma-separated, or none (stripe, resend, s3, google, microsoft, slack, github, twilio, paystack, flutterwave, bachs, auth0, clerk, composio, nylas, nango, unipile, llm) |
--skills <list> | coding agents to install danwo's skill for, comma-separated, or none (claude, cursor, codex, copilot, agents) |
--no-mcp | do not register danwo's MCP server with those agents |
--dev-command <command> | the command that starts the app, e.g. 'pnpm dev' |
--app-url <url> | where the app answers once started |
--skip-install | write the files but install no packages |
--force | replace a danwo.config.ts that differs from the one init writes |
doctor
command
danwo doctorcheck what a first run needs: Node, danwo's Chromium, the config and its keys, the model's key, Playwright Test's version and the agents' skill
| Member | Description |
|---|---|
--json | the checks as JSON: { ok, checks: [{ name, status, detail }] } |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
install-browser
command
danwo install-browserinstall the Chromium build danwo drives, with danwo's own Playwright, once per machine; other Playwright installs' browsers are kept
| Member | Description |
|---|---|
--with-deps | also install the system libraries Chromium needs (Linux) |
--only-shell | only the headless shell test runs use (smaller, for CI); not for danwo record |
--dry-run | say what would be installed, and install nothing |
record
command
danwo record [path]record a test by using the app in a browser: locators for each action, what it caused behind the app, and a drafted invariant
| Member | Description |
|---|---|
path | the app page to start on |
-o, --out <file> | the new test file, relative to the project (default: /recorded.danwo.ts) |
default recorded journey | the test's title |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
show
command
danwo show [run-id]print the path of a recorded run's report (the newest by default)
| Member | Description |
|---|---|
run-id | a run under .danwo/runs |
-o, --open | open the report in the browser |
html | md, default html | html: the report's path; md: a failure page for each failed run |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
lint
command
danwo lint [run-id]run the integration lint again over a recorded run (the newest by default); record passing runs too with --record always
| Member | Description |
|---|---|
run-id | a run under .danwo/runs |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
serve
command
danwo servestart the dashboard: runs, flight records, matrix grids and flaky tests from .danwo
| Member | Description |
|---|---|
-p, --port <port> | port on 127.0.0.1 (default 4310; 0 picks a free one) |
-o, --open | open the dashboard in the browser |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
cache
command
danwo cache <action>list, count or clear the replay cache's recordings
| Member | Description |
|---|---|
ls | stats | clear | |
-j, --journey <test-id> | only the recordings of this test |
-c, --config <path> | config file (default: nearest danwo.config.ts) |
spec
command
danwo specprint what this danwo provides, generated from its code: API, config, faults, codes
| Member | Description |
|---|---|
--json | compact JSON instead of text |
-t, --topic <topic> | one section: api, fixtures, locators, expect, agent, secrets, config, environments, emulators, faults, cli, errors, cache, lint, exports |
fidelity
command
danwo fidelity [providers...]check the emulators against the real providers' sandboxes (with DANWO_FIDELITY_* credentials) or the committed goldens
| Member | Description |
|---|---|
providers | providers to check (default: all); login google|microsoft signs a test account in instead |
--update-golden | keep the sandbox's (or the API description's) structure as the new golden |
--from-openapi [file] | make goldens from API descriptions: a file for one provider, or each provider's published one |
--offline | compare against the goldens even when credentials are set |
--keep | leave what live runs make in the sandboxes, listed as kept, instead of undoing it |
--sweep | list leftovers tagged danwo-fidelity from earlier live runs instead of checking; --yes removes them |
--yes | with --sweep, remove the tagged leftovers it lists |
--root <dir> | the danwo repository holding fidelity/ (default: the current folder) |
--redirect-uri <uri> | with login: the redirect URI the OAuth client registers (default: DANWO_FIDELITY__REDIRECT_URI, else http://127.0.0.1:8765/callback) |
--port <port> | with login: the port of the default redirect URI |
guide
command
danwo guide [topic]list task guides, or print one
| Member | Description |
|---|---|
topic | a guide's topic; without one, the list |
device
command
danwo device <action>check this machine for mobile testing: Android (SDK, adb, emulator, rootable images, AVDs, JDK) and, on a Mac, iOS (Xcode, simctl, runtimes, CocoaPods)
| Member | Description |
|---|---|
doctor | |
android | ios | check one platform only |
build-android
command
danwo build-android [project]build the danwo build of an Expo app as a release APK (trusting danwo's per-run CA); unchanged sources reuse the kept build
| Member | Description |
|---|---|
project | the Expo project's folder |
--force | build again even when the sources are unchanged |
--verbose | print the build tools' output |
build-ios
command
danwo build-ios [project]build the danwo build of an Expo app as a Release iOS Simulator app (plain HTTP allowed for the proxy); unchanged sources reuse the kept build
| Member | Description |
|---|---|
project | the Expo project's folder |
--force | build again even when the sources are unchanged |
--verbose | print the build tools' output |