Skip to main content
The Workbench is a Chrome side panel for working against a running coordinator: browse VPoint definitions, write CEL with autocomplete and diagnostics, insert session-scoped stages, and inject the x-varianz-id header into the requests you choose. It needs a coordinator to talk to — see Running the coordinator locally if you don’t have one.
The extension is published as Varianz Workbench (beta) and versioned with the rest of the release.

​
Install

There is no Chrome Web Store listing yet. The zip below is the only install route today. It does not auto-update — re-download to move to a new version.
Every release publishes the extension to pkgs.varianz.io anonymously, the same no-credential access as the SDK packages:
Then in Chrome:
  1. Go to chrome://extensions
  2. Turn on Developer mode (top right)
  3. Click Load unpacked and select the varianz-workbench directory
Chrome shows a “disable developer mode extensions” prompt on some platforms. That is expected for any unpacked extension.

​
Verifying the download

The zip is covered by a cosign-signed checksum manifest, published beside it and fetched the same anonymous way:
verify-packages.sh, shipped with every release, checks the signature and the checksum together and is the supported path:
To do it by hand, verify the manifest’s signature first, then compare the hash:
Entries in the manifest are named varianz-workbench:<version>:varianz-workbench-<version>.zip, not by bare filename, so a plain sha256sum --check extension-SHA256SUMS reports “no file was verified” rather than checking anything. Use verify-packages.sh, or compare the hashes as above.

​
What it asks for, and why

The extension installs holding host access to localhost only — localhost, 127.0.0.1 and *.localhost. It cannot read or change anything on any other site until you ask it to. When you add a header-injection rule for another host, Chrome prompts you for that one host and stores the rule only if you allow it. The same prompt appears if you point the connection bar at a coordinator that is not local. Review and withdraw these grants at any time from chrome://extensions → Varianz Workbench → Site access. The manifest declares sidePanel, declarativeNetRequestWithHostAccess, storage, activeTab, tabs and alarms. Two are worth explaining because Chrome describes them alarmingly:
  • declarativeNetRequestWithHostAccess sets exactly one request header, x-varianz-id, and only on hosts you have explicitly added.
  • tabs, which Chrome describes as reading your browsing history, is used for one thing: reading the active tab’s address, so the + Tab button can offer that domain and a localhost dev server can be seeded as a rule on first use.
optional_host_permissions is *://*/*, but it is never requested wholesale — the extension asks for one origin at a time, on a user gesture. Nothing is loaded remotely; everything is bundled at build time.
Address a local coordinator as localhost, not [::1]. Rules match by domain name, and Chrome has no bracketed-IPv6 form for a rule condition — an IPv6 literal is refused when you add it.

​
Choosing a version

The extension talks to the coordinator over gRPC-web with generated protocol clients, so a build is matched to the coordinator release it shipped with. Run the version that matches your coordinator. If something looks wrong after upgrading one but not the other, that is the first thing to check.