Vibium: Browser Automation for AI Agents and Testers

Vibium is an AI-oriented browser automation tool built on WebDriver BiDi. Its official docs describe it as browser automation for AI agents and humans, and the current installation page names vibium@26.8.21 as the latest npm release while the nightly docs explicitly compare nightly builds against that version. That means you need to read the docs with version awareness: several exciting AI commands, including vibium run, vibium ready, vibium setup, and the newer AI-verdict form of vibium check, are documented as nightly-only at the time I verified them.

For QA engineers, Vibium is interesting because it treats the browser as an evidence device for agents. Instead of only exposing a test framework API, it gives scripts and assistants a compact command surface: open a page, map elements, click a referenced element, read text, record evidence, and verify a claim. That overlaps with ideas in Browser Use AI Agent Testing Guide, but Vibium's foundation is WebDriver BiDi rather than a custom browser-control loop.

The short recommendation is this: evaluate Vibium when your team wants agents to inspect and verify real browser state without making Playwright the whole testing substrate. Keep Playwright, Selenium, Cypress, or WebdriverIO for established suites unless you have a clear migration reason. Vibium is best treated as a verification layer, agent tool, and lightweight automation surface, not as a drop-in replacement for every mature test runner feature.

Current Product Status And Version Reality

The official Vibium site and repository are active. The docs mention JS/TS, Python, and Java client libraries, a CLI, MCP integration, recordings, Chrome by default, Firefox support through native WebDriver BiDi, and machine-readable docs for agents. The installation page lists Node.js 18+ for the npm installer and JS client, supported platforms of Linux x64 or arm64, macOS x64 or arm64, and Windows x64, and a managed Google Chrome for Testing download on first browser use.

The part to be careful with is release channel language. The latest stable release is v26.8.21 (August 22, 2026), which is also the npm latest tag, and the GitHub Releases page is busy with prerelease nightly builds published almost daily. The nightly docs page is generated by diffing current nightly builds against vibium@26.8.21. For a test suite, pin the stable npm version and treat anything documented only on the nightly page as unavailable until a stable release ships it.

Capability	Verified status in docs	QA interpretation
CLI install	npm install -g vibium and npx -y vibium ... are documented	Good for local exploration and CI smoke checks
Latest npm baseline	Docs compare nightly builds against vibium@26.8.21	Pin and verify the actual installed package
WebDriver BiDi	Docs state Vibium is built on WebDriver BiDi	Standards-based control path, not CDP-only
Chrome for Testing	Managed download on first browser use	Fewer driver-version chores
Firefox	Supported through native WebDriver BiDi	Useful for standards validation, with documented differences
MCP	Docs and repo describe MCP support	Useful for Claude Code, Cursor, and MCP-compatible agents
Run and Check AI commands	Documented as nightly-only for now	Do not build stable CI on them without pinning nightly

Vibium is associated publicly with Jason Huggins, known for Selenium, through the GitHub release identity and project presence. The technical implication is more important than the biography: the project leans toward open browser standards and verification workflows rather than a browser-specific DevTools abstraction.

Install And Verify Without Assuming Nightly Features

Start with the stable CLI. The docs say a global npm install gives you the vibium binary, and the first command that needs a browser downloads a managed Chrome for Testing build. If you do not want a global install, the docs show npx -y vibium as a zero-install path.

npm install -g vibium
vibium go https://example.com
vibium text

For one-off trials:

npx -y vibium go https://example.com
npx -y vibium screenshot -o example.png
npx -y vibium text

For a project, install the client library in dev dependencies or normal dependencies depending on whether browser verification runs only in tests or also in developer tooling.

npm install --save-dev vibium
uv add --dev vibium

Do not begin a QA rollout by asking an agent to use vibium run unless you have installed a build that actually includes it. The Run and Check docs mark those AI features as nightly-only for now and say vibium check in 26.8.21 still toggles a checkbox. That is not a minor footnote. It changes what a command means.

Command or feature	Stable docs posture	Rollout advice
vibium go	Stable install verification path	Safe for smoke scripts
vibium text	Stable install verification path	Good for basic assertions
vibium add-skill	Documented for agent skills	Useful for Claude Code and Grok
vibium ready	Nightly-only in command docs	Use only after selecting nightly
vibium run	Nightly-only in command docs	Keep outside required CI initially
AI-verdict vibium check	Nightly-only behavior	Inspect version before scripting
vibium pipe --connect-caps	Marked as nightly-only	Do not rely on it in stable jobs

The first QA task is therefore a version probe. Use your package manager to print the installed version, then run one command that opens a page and one command that reads state. If either fails, fix browser installation before touching tests.

node -e "const pkg=require('vibium/package.json'); console.log(pkg.version)"
npx -y vibium go https://example.com
npx -y vibium text

That sample assumes the npm package exposes package.json through normal Node resolution. If your package manager blocks package internals, use npm ls vibium instead.

The WebDriver BiDi Foundation

Vibium's docs explain WebDriver BiDi as the standard behind the project. Classic WebDriver is request-response over HTTP. Chrome DevTools Protocol is bidirectional and powerful, but historically Chrome-centered. WebDriver BiDi combines bidirectional WebSocket communication with a standards process and browser vendor participation.

For QA engineers, that matters in three practical ways. First, browser events can flow back to the client without polling everything. Second, Firefox support does not require a separate driver binary in Vibium's documented path because Firefox speaks native BiDi. Third, the tool has a plausible standards story for future browser coverage instead of being tied to one vendor's private protocol.

Automation layer	Transport and model	Vibium relevance
Classic WebDriver	HTTP request-response	Still important for Selenium Grid history
Chrome DevTools Protocol	WebSocket, Chrome-specific protocol family	Powerful, but not Vibium's stated foundation
WebDriver BiDi	WebSocket, W3C standard direction	Vibium's core browser-control foundation
MCP	JSON-RPC style tool interface for agents	Lets agents invoke browser actions through tools
CLI daemon sessions	Local process maintaining browser state	Lets shell commands share a live browser

This is also where the Selenium comparison gets interesting. Selenium 4's BiDi work and Grid story are covered in Selenium 4.43 BiDi Grid Kubernetes Notes. Vibium is not Selenium Grid with a friendlier wrapper. It is a separate tool that uses BiDi to give agents and scripts a compact interface. If you already run Selenium Grid at scale, look at Vibium's pipe --connect path as an integration experiment, not a wholesale replacement.

CLI Workflow: Map, Act, Read, Record

The most agent-friendly Vibium workflow is not "write a giant test file first". It is map, act, read, and record. The docs describe a loop where the browser session exposes interactive elements, the script or agent chooses a reference, acts, and reads visible state back.

A basic manual sequence can look like this:

vibium go https://example.com
vibium text
vibium screenshot -o example.png

For pages with interaction, the docs show element references such as @e1 in the recording examples. A recorded session can capture the evidence around those actions.

vibium record start -o checkout.zip
vibium go https://staging.example.com/checkout
vibium find text "Continue"
vibium click @e1
vibium record stop

That pattern is useful during bug triage. An agent can drive the page, but the recording becomes reviewable evidence for humans. The docs say recordings include action traces, screenshots per step, optional HTML snapshots, and on Firefox a native video track when the engine supports it.

What people get wrong: they treat element references as durable selectors. @e1 is a reference in the current mapped session, not a design contract. It is perfect for the next action after a map. It is not a long-term selector to paste into a permanent suite. Permanent checks should express the intended text, label, role, or stable selector according to the client API or command available in your version.

JSON Output And Exit Codes For CI

Vibium's scripting docs are unusually important because they warn against a common automation mistake. Every command can accept --json and return an envelope with ok and result or error. The docs also say run and check can exit 0 when they deliver a verdict, even if the goal was not completed or the claim failed. In automation, you must inspect the result payload.

vibium --json url
vibium check "the cart shows one item" --json
vibium run "add a battery pack to the cart" --json

Use a small Node verifier around JSON output instead of relying on shell truthiness.

import assert from 'node:assert/strict';
import { spawnSync } from 'node:child_process';

const result = spawnSync('vibium', ['--json', 'url'], {
  encoding: 'utf8',
});

assert.equal(result.status, 0, result.stderr);
const envelope = JSON.parse(result.stdout);
assert.equal(envelope.ok, true);
assert.match(envelope.result.url, /^https?:\/\//);

That regex is anchored and the test checks process status, JSON parseability, envelope success, and result shape. This is the standard you want agents to follow. If an agent writes "run command and hope exit 0 means page is correct", ask it to inspect the contract.

A CI smoke job can install the package, open a page, capture text, and upload evidence. Keep this separate from experimental nightly AI actions.

name: vibium-smoke

on:
  pull_request:
  workflow_dispatch:

jobs:
  browser-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npx vibium go https://example.com
      - run: npx vibium text
      - run: npx vibium screenshot -o vibium-example.png
      - uses: actions/upload-artifact@v7
        if: always()
        with:
          name: vibium-smoke-${{ github.run_id }}
          path: vibium-example.png

If you run parallel jobs, do not let all of them share one local daemon session by accident. The sessions docs say one-shot CLI commands share a background daemon by default. Use VIBIUM_SESSION or --session to separate jobs.

export VIBIUM_SESSION=checkout-pr-123
vibium go https://staging.example.com/checkout
vibium text
vibium daemon stop

MCP For Claude Code, Cursor, And Other Agents

Vibium's repo and docs describe MCP support. Older update notes show a clicker mcp server with tools such as browser start, navigate, click, type, screenshot, find, and stop. Current docs describe Vibium skills, vibium add-skill, and MCP exposure for vibium_run and vibium_check in the AI feature path. The exact tool list can change across releases, so pin the package and read the generated command reference before standardizing prompts.

The stable operational idea is simple: MCP turns browser operations into tools an agent can call. That makes it different from asking the agent to emit code and then run the code. The agent can inspect the current browser, click, screenshot, and adjust.

vibium add-skill
vibium add-skill --agent claude
vibium add-skill --agent grok

For QA teams, agent enablement should include boundaries:

Boundary	Why it matters	Practical rule
Environment	Agents may browse production by mistake	Start from staging URLs and explicit sessions
Credentials	Browser state can leak screenshots	Use seeded test users, never personal accounts
Evidence	Agent claims need review	Save screenshots or recordings for nontrivial changes
Version	Stable and nightly commands differ	Pin package and document available commands
Cleanup	Daemons keep browser state alive	Stop sessions after CI and local reproductions

Compared with Playwright MCP, Vibium is less about giving an agent access to the Playwright testing ecosystem and more about giving it a compact browser verification tool. Playwright MCP is attractive when your suite, fixtures, and selectors are already Playwright-native. Vibium is attractive when the agent needs a small browser-control surface that can run from CLI, MCP, and client libraries without adopting Playwright Test as the organizing framework.

JS And Python Clients Without Over-Abstracting

The official repo shows a JS/TS client with browser.start(), bro.page(), page.go(), page.screenshot(), page.find(), and element click(). The installation docs say Python and Java clients exist and that each client bundles or locates the same Vibium binary. The using-Firefox docs also show JS and Python launchers for Firefox.

A JS smoke script based on the repo example can remain tiny:

import assert from 'node:assert/strict';
import fs from 'node:fs/promises';
import { browser } from 'vibium';

const bro = await browser.start();

try {
  const page = await bro.page();
  await page.go('https://example.com');
  const png = await page.screenshot();
  assert.ok(png.length > 1000);
  await fs.writeFile('example.png', png);

  const link = await page.find('a');
  assert.ok(link);
  await link.click();
} finally {
  await bro.stop();
}

For Firefox, the docs show a named launcher and an engine option:

import { firefox, browser } from 'vibium';

const firefoxBrowser = await firefox.start();
await firefoxBrowser.stop();

const explicit = await browser.start({ engine: 'firefox' });
await explicit.stop();

In Python, keep to verified launcher shape if you are documenting Firefox startup:

from vibium import firefox

bro = firefox.start()
try:
    pass
finally:
    bro.stop()

The discipline here is to avoid building a private framework too soon. Wrap only the parts your team repeats: session naming, base URL choice, evidence path, and cleanup. Let Vibium's client remain visible until the workflow stabilizes.

Firefox, Channels, And Browser Pinning

Vibium launches Chrome by default. The Firefox docs say Firefox is supported as an alternative engine using native WebDriver BiDi, no driver binary involved. On macOS and Linux, the binary auto-installs the selected engine on first launch. On Windows, Firefox auto-install is not available, so you install Firefox yourself and point VIBIUM_ENGINE_PATH at firefox.exe.

vibium install --engine firefox
vibium start --engine firefox
VIBIUM_ENGINE=firefox vibium go https://example.com

The docs also distinguish stable support from nightly channel controls. --channel beta and VIBIUM_ENGINE_CHANNEL=beta select Firefox beta. Nightly builds extend channels to Chrome with stable, beta, dev, and canary, and add VIBIUM_ENGINE_VERSION for exact version pinning.

Variable or flag	Documented effect	QA use
--engine firefox	Run a command with Firefox	Cross-engine smoke check
VIBIUM_ENGINE=firefox	Default engine when flag omitted	CI job-level browser selection
VIBIUM_ENGINE_PATH	Use a specific Firefox executable on Windows	Locked-down Windows runners
VIBIUM_ENGINE_CHANNEL	Select browser channel	Beta validation
VIBIUM_ENGINE_VERSION	Pin exact version in nightly builds	Fleet reproducibility

Do not mistake "Firefox supported" for "all outputs identical". The docs call out feature differences, including native video recording requiring Firefox 154+ and PDF output differences. Cross-browser testing still needs assertions based on user-visible behavior, not pixel-perfect assumptions unless the point of the test is visual output.

A Real Failure Mode: Passing Command, Failed Claim

Here is the Vibium failure mode that will bite teams using AI agents: the command exits 0, the agent reports success, but the goal was not actually achieved. The docs warn that run exits 0 when the operation completed, whether the status is completed or not completed. check exits 0 when a verdict was delivered, even if the verdict is FAIL or INCONCLUSIVE.

The diagnosis is not "Vibium is flaky". The diagnosis is "your harness confused command execution with test success". Add JSON inspection and require the semantic status you expect.

import assert from 'node:assert/strict';
import { spawnSync } from 'node:child_process';

function runJson(args) {
  const proc = spawnSync('vibium', args, { encoding: 'utf8' });
  assert.equal(proc.status, 0, proc.stderr);
  const parsed = JSON.parse(proc.stdout);
  assert.equal(parsed.ok, true);
  return parsed.result;
}

const result = runJson([
  'run',
  'add a battery pack to the cart',
  '--base-url',
  'http://localhost:3000',
  '--json',
]);

assert.equal(result.status, 'completed');
assert.ok(Array.isArray(result.evidence));
assert.ok(result.evidence.length > 0);

That code is intentionally strict. It checks process status, parses JSON, validates the envelope, requires completed status, and demands evidence. The exact result shape can evolve, so update the assertion to your installed version's contract, but keep the principle: a delivered verdict is not the same as a passed test.

Where Vibium Fits Beside Existing Test Tools

Vibium is easiest to justify as an addition to a QA stack, not as a rushed replacement. Mature suites have fixtures, retries, reporters, page objects, accessibility helpers, test data setup, and CI sharding. Vibium's value is narrower and sharper: let humans and agents operate a browser, gather evidence, and verify state through a standards-based control layer.

Team situation	Vibium role	Keep using
Agents need browser access during code repair	MCP or CLI verification tool	Existing unit and e2e test suites
QA wants lightweight staging smoke checks	CLI scripts with screenshots and text checks	Full regression suite elsewhere
Selenium shop evaluating BiDi	Standards experiment and agent layer	Selenium Grid for broad compatibility
Playwright shop with strong fixtures	Occasional external verifier	Playwright Test for core coverage
Product team needs reviewable repro evidence	Recordings and screenshots	Bug tracker and normal triage process

The best first rollout is small. Pick one staging workflow, one seeded account, one session name, one screenshot artifact, and one clear assertion. Then invite an agent to help expand only after the first workflow is boringly reliable.

Frequently Asked Questions

Is Vibium stable enough for required CI gates?

Use the stable CLI pieces cautiously for smoke checks, especially go, text, screenshots, sessions, and recordings. Be more careful with AI features marked nightly-only, such as run, ready, setup, and the AI-verdict behavior of check. For required CI, pin the package, verify the installed version, inspect JSON output, and avoid relying on commands that your installed channel does not include.

How is Vibium different from Playwright MCP?

Playwright MCP gives agents access to a browser through the Playwright ecosystem, which is ideal when your tests, fixtures, and debugging habits already live in Playwright. Vibium focuses on a compact CLI, MCP, and client-library surface built on WebDriver BiDi. It is a good verifier for agents and QA scripts, but it does not replace the full Playwright Test platform for teams already invested there.

Does Vibium replace Selenium Grid?

No. Vibium can connect to remote BiDi or classic WebDriver endpoints through documented pipe --connect flows, and the docs mention classic WebDriver endpoint handling where Vibium creates a session and connects to the returned BiDi URL. That makes it interesting beside Selenium infrastructure. It does not automatically replace Grid scheduling, enterprise browser matrices, or the operational practices around large Selenium fleets.

What should QA teams check before adopting Vibium?

Check the installed version, release channel, browser install behavior, supported operating systems, session isolation, JSON result contracts, and evidence capture. Then run one workflow against staging with a seeded account and uploaded screenshots or recordings. The most important adoption question is not whether Vibium can click a button. It is whether your team can trust, review, and reproduce what an agent did in the browser.