testvibe

TestVibe from your terminal and your AI tools: manage features, run Playwright tests in cloud sandboxes, generate tests from Gherkin, run load tests, and edit project files. testvibe mcp exposes the same operations as an MCP server for Claude Desktop, Claude Code, Codex, and other MCP clients.

A single bundled file with zero runtime dependencies — all it needs is Node 20+.

Install

npm install -g testvibe

Then log in once per machine with an API key from TestVibe → Settings → CLI & API keys:

testvibe login --server https://testvibe.app --key tvb_XXXXXXXX…
testvibe use <project>

Commands

| Command | What it does | | --- | --- | | testvibe login / logout / whoami | Store, remove, or show the API key for this machine. | | testvibe use <project> | Set the default project. | | testvibe projects / project [id] | List projects / show one project's details. | | testvibe features [list\|show\|create\|update\|delete] | Manage features and their Gherkin. | | testvibe generate <feature> [--watch] | Generate Playwright tests from a feature's Gherkin. | | testvibe run <feature>\|--all [--wait] | Run tests in a cloud sandbox; --wait prints per-test results. | | testvibe runs [list\|show\|diagnose\|artifacts] | Inspect runs and failure context; artifacts issues download links. | | testvibe files [list\|get\|put\|delete] | Read and write project files. | | testvibe load [list\|create\|update\|delete\|run] | Manage and dispatch load tests (features or k6 paths). | | testvibe telemetry [live\|errors\|metrics] | Read live server vitals, error groups, and run server metrics. | | testvibe automations … | Manage schedule/event-triggered runs. | | testvibe coverage … | Coverage snapshot, AI area scans, execution-coverage runs. | | testvibe plugins … / vars / secrets | Plugin catalog, project variables, and secrets. | | testvibe mcp | Start the MCP stdio server. | | testvibe version / --version / -v | Print the installed CLI version (bare number, exit 0). |

Run testvibe --help for full flags on every command.

Artifact links are credentials

testvibe runs artifacts <runId> mints short-lived signed URLs (?...&sig=...) for a run's traces, screenshots, videos and reports. That sig= is a bearer credential: whoever holds the string can read that blob until the se= expiry, no login involved. That command exists to hand them out, so it does.

testvibe runs diagnose <runId> does not. Diagnose output is failure context — the text you paste into a Jira ticket, a GitHub issue or a Slack thread when you ask someone for help, and the text that ends up on screen in a recorded terminal — so it prints artifact blob paths and stops there:

  trace: accounts/12/projects/37/runs/1078/trace.zip
  (artifact paths, not download links — `testvibe runs artifacts 1078` issues short-lived signed URLs, or re-run with --links.)

This holds for --json as well, which drops the url field and leaves {kind, path, size} — the same shape get_run already returns. A path is what testvibe runs trace --path <path> wants anyway, so the usual "look at the trace" loop never needed the credential. Pass --links to put the signed URLs back in either format when you actually intend to share downloads.

Waiting, and what the exit code means

--wait (--watch on generate) polls until the work reaches a terminal state. A run is still in flight in queued, allocating and running — none of those is an outcome, and none of them is a failure.

| Exit code | Meaning | | --- | --- | | 0 | Everything finished and passed / succeeded. | | 1 | It finished and something actually failed. | | 2 | A generation parked to ask you a question — it needs a human, nothing is broken. | | 3 | We stopped waiting: the --timeout ceiling elapsed, or we lost contact with the server. No verdict — the work may still be running, and this never means your tests failed. |

--timeout <seconds> caps how long a --wait/--watch polls, as one budget for the whole command (a suite of 19 runs still waits at most this long in total). It defaults to 5400 s and can be set with TESTVIBE_WAIT_TIMEOUT_SECONDS; --timeout 0 waits indefinitely.

MCP server

Point any MCP client at testvibe mcp (stdio). For example, for Claude Code:

claude mcp add testvibe -- npx -y testvibe mcp

The server exposes the same operations as the CLI — features, generation, runs, load tests, telemetry, files, and more — scoped to your API key.

Configuration

testvibe login stores the server URL and key in ~/.testvibe/config.json; TESTVIBE_SERVER, TESTVIBE_API_KEY, and TESTVIBE_PROJECT environment variables override it (handy for CI). Self-hosting? Point --server at your own TestVibe instance.

License

Copyright © ICE TEA GROUP LLC. All rights reserved.