> ## Documentation Index
> Fetch the complete documentation index at: https://docs.varianz.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Workbench browser extension

> Install and use the Varianz Workbench Chrome extension: browse VPoints, write CEL with autocomplete, insert session-scoped stages, and inject the x-varianz-id header.

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](/reference/local-coordinator) if you don't have one.

<Note>
  The extension is published as **Varianz Workbench (beta)** and versioned with the rest of the release.
</Note>

## Install

<Warning>
  **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.
</Warning>

Every release publishes the extension to `pkgs.varianz.io` anonymously, the same no-credential access as the SDK packages:

```bash theme={null}
VERSION=0.2.3
curl -fLO "https://pkgs.varianz.io/extension/varianz-workbench/${VERSION}/varianz-workbench-${VERSION}.zip"
unzip "varianz-workbench-${VERSION}.zip" -d varianz-workbench
```

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:

```bash theme={null}
VERSION=0.2.3
BASE="https://pkgs.varianz.io/extension"
curl -fLO "${BASE}/varianz-checksums-extension/${VERSION}/extension-SHA256SUMS"
curl -fLO "${BASE}/varianz-checksums-extension-sig/${VERSION}/extension-SHA256SUMS.sig"
```

`verify-packages.sh`, shipped with every release, checks the signature and the checksum together and is the supported path:

```bash theme={null}
./verify-packages.sh --version "$VERSION" "varianz-workbench-${VERSION}.zip"
```

To do it by hand, verify the manifest's signature first, then compare the hash:

```bash theme={null}
# The public key ships with every release as varianz-cosign-pubkey.
#
# --insecure-ignore-tlog is required and does not weaken the check: Varianz
# releases are signed with --tlog-upload=false, so cosign must be told not to
# look for a transparency-log entry. The signature is still checked against the
# key, which is what proves authenticity.
cosign verify-blob --insecure-ignore-tlog=true --key cosign.pub \
  --signature extension-SHA256SUMS.sig extension-SHA256SUMS

grep "varianz-workbench-${VERSION}.zip" extension-SHA256SUMS | awk '{print $1}'
shasum -a 256 "varianz-workbench-${VERSION}.zip" | awk '{print $1}'
```

<Note>
  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.
</Note>

## 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.

<Warning>
  **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.
</Warning>

## 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.