Fix: Vibium Version Mismatch Errors

A Vibium version mismatch almost always means a stale client or a cached Chrome for Testing left over from an older release — the fix is to upgrade the client and let Vibium re-download a matching browser. Since version 26.2, Vibium pins a known-good Chrome for Testing to each release and no longer falls back to unreliable system Chrome, so the client and browser are meant to move together. Run vibium version to see your build (Vibium uses calendar versioning, so 26.2 means February 2026), upgrade with pip install -U vibium or npm install vibium@latest, then run vibium install to fetch the Chrome that matches. If you mix a new client with a cached old browser — or run mismatched Python and Node clients against the same project — you get errors. Aligning everything to the latest release resolves nearly every mismatch. For background on the architecture, see what is Vibium.

Why do version mismatch errors happen in Vibium?

Vibium ships as a single Go binary that downloads its own Chrome for Testing, and each Vibium release pins a specific, known-good Chrome build. A mismatch happens when those two drift apart: you upgraded the client but an older Chrome is still cached, you have two clients (Python and Node) of different ages pointing at the same machine, or a CI image baked in an old browser. As of 26.2, Vibium requires Chrome for Testing and removed the unreliable system-Chrome fallback — which is good for reproducibility, but it means a stale cached browser surfaces as an explicit version error instead of silently limping along.

How do I check which Vibium version I'm running?

Start by confirming exactly what's installed. On the CLI:

vibium version

Then check the language client itself:

# Python
pip show vibium
 
# Node
npm list vibium

Because Vibium uses calendar versioning, the version string is a date: 26.2 is February 2026. Comparing two version strings tells you instantly which build is newer, with no semver guesswork.

How do I fix the mismatch?

The reliable fix is to upgrade the client and let Vibium fetch a matching Chrome. For Python:

pip install -U vibium
vibium install   # re-download the matching Chrome for Testing

For Node:

npm install vibium@latest
npx vibium install

vibium install pre-downloads the Chrome for Testing build that the current client expects, so the client and browser are back in lockstep. After upgrading, re-run your script — the mismatch error should be gone.

What if a stale cached browser is still being used?

If you upgraded but still see a wrong-Chrome error, an old cached browser is being picked up. Clear it and re-fetch:

# See where Vibium stores its binaries and browsers
vibium paths
 
# Re-download the correct Chrome for Testing
vibium install

vibium paths shows the cache locations so you can confirm what's there. After vibium install pulls the matching browser, launch a quick smoke test to verify:

from vibium import browser_sync as browser
 
vibe = browser.launch()
vibe.go("https://example.com")
print(vibe.find("h1").text())
vibe.quit()

If that runs cleanly, the client and browser are aligned. See find element for more on the find() API used here.

Why do my Python and Node clients disagree?

If you automate from both languages, keep them on the same release. A 26.2 Python client and a months-old Node client can expect different Chrome builds or API surfaces, producing confusing mismatch errors. Pin both to the same version:

pip install "vibium==26.2"
npm install vibium@26.2

Vibium aims for full API parity across Python sync, Python async, JS sync, JS async, the CLI, and MCP — but that parity is per-release. Pinning a single version across every client in a project removes drift entirely. The same applies to your MCP setup: keep the MCP server on the same Vibium version as your scripts.

How do I prevent version mismatches in CI?

Three habits keep CI green:

• Pin the client to an exact version (vibium==26.2) so an upstream release doesn't change behavior mid-pipeline.
• Pre-fetch the browser at build time with vibium install in your image or provisioning step, so cold starts use the matching Chrome and never pull a surprise build.
• Don't rely on system Chrome — Vibium no longer uses it, so removing any old CHROME_PATH overrides avoids pointing the client at an incompatible browser.

With the client pinned and a matching Chrome baked in, every run uses the exact same client/browser pair. See how to run Vibium on a server for the full CI and Docker pattern.

Next steps

• What is Vibium?
• How to run Vibium headless on a server
• Find element command reference