Get started

Run the demo

npx onbehalf demo

That unpacks two recorded runs of the same support-desk agent onto your machine and prints three commands. No network, no API key, no account, no tokens spent — and nothing is written until you type demo. It writes only under BEHALF_DEMO_HOME, else demo/ under BEHALF_HOME, else ~/.behalf/demo, and prints the export BEHALF_HOME=… line to paste.

npx onbehalf runs                        # two runs of one agent. both ok.
npx onbehalf diff run_9f2a run_c71e      # which step made them differ
npx onbehalf why run_c71e:31             # and on whose behalf it was done

npx runs from npm’s cache and puts nothing on PATH, so the commands are written the way they work. Both export files are in the package (node_modules/onbehalf/demo/); the same two runs are rendered at /demo/.

Install

Registry	Package	What you get
npm	onbehalf	npm install -g onbehalf puts behalf, behalf-log and behalf-verify on PATH.
crates.io	behalf-verify	cargo install behalf-verify — the offline verifier on its own, built from source.
Go	github.com/behalf-sh/behalf	go install github.com/behalf-sh/behalf/cmd/behalf@latest; likewise cmd/behalf-log, cmd/behalf-proxy, cmd/behalf-hook.

The npm package has no postinstall script and no fat tarball. The platform binaries are separate packages — @onbehalf/cli-darwin-arm64, @onbehalf/cli-darwin-x64, @onbehalf/cli-linux-arm64, @onbehalf/cli-linux-x64 — declared as optionalDependencies and selected by npm’s own os/cpu fields, so you download one platform’s binaries and run no install-time script. An install-time download from somewhere else is exactly the unauditable step this tool exists to remove. Releases are published over npm trusted publishing (OIDC) with provenance attestations.

onbehalf@0.1.0 is deprecated on the registry: its binaries shipped without the executable bit, so npx onbehalf demo failed with EACCES. Any later version is fine.

What is in the box

Binary	What it is
behalf	the CLI: runs, diff, why, export --html, login, whoami
behalf-log	the local log: import, export, reindex, rehydrate, and the service commands
behalf-verify	the independent offline verifier, written in Rust

behalf-verify is a separate implementation on purpose. The claim is don’t take our word for it, run it yourself, and a verifier that shared code with the writer would not be a second opinion. The two are pinned against each other by cross-implementation conformance vectors on every commit.

The npx onbehalf launcher

npx onbehalf demo [--again]     unpack two recorded runs and print what to type
npx onbehalf where              print the paths of the installed binaries
npx onbehalf <command> …        anything else is passed to the behalf CLI:
                                  runs, diff, why, export, login, …
npx onbehalf verify <file>      the offline verifier (behalf-verify)
npx onbehalf log <command> …    the log service CLI (behalf-log)

The verifier and its exit codes

behalf-verify run_c71e.jsonl          # an export file
behalf-verify log <dir>               # a live tile directory (needs a filesystem)

A clean run prints what it checked and, on every run, what it did not:

✔ 47/47 receipts intact   chain head 7189…93ee
✔ 94 delegation hop(s) checked: I1 authority, I2 depth, I3 expiry, I5 linkage
  not checked here: I4 capability monotonicity, I6 proof of possession, and the identity root
  47 hop(s) caller-asserted: no token accompanies them, so nothing about them was checked

Exit codes are stable and documented: 0 verified, 1 tampering detected, 2 unverifiable (not a readable export). Each failure also produces one machine-readable line on stderr, class=<content|drop|reorder|chain|truncation|head|duplicate|delegation> index=<N> (-1 where no leaf index applies), so CI can gate on the code and log the class. The full contract — check order, tamper classes, index conventions — is the export format. The same crate compiled to WebAssembly runs at /verify/: file mode only, nothing uploaded.

Platforms

macOS and Linux, each on x64 and arm64. Not Windows: the log’s storage driver is POSIX-only (flock(2), O_DIRECTORY) and does not compile there, so neither behalf nor behalf-log does, and the demo needs both. The Rust verifier alone cross-compiles. WSL runs everything; the @onbehalf/cli-win32-* names are reserved and deprecated with that sentence.

Licence

Path	Licence
cmd/behalf-log/**, cmd/behalf-witness/**	FSL-1.1-ALv2 — each release converts to Apache-2.0 two years after it ships
everything else — verifier, CLI, capture surfaces, schemas, packaging	Apache-2.0

Everything that lets you check the record is permissively licensed and stays that way; the durable log service and the witness are not, for their term. FSL is not an open-source licence during that term. The npm package is Apache-2.0 throughout: it ships no FSL binary. The map is LICENSING.md.

Not built yet

• Published key log — so an export’s keys can be attributed to a real emitter. Today every export embeds the public keys it needs, and the verifier is explicit that it checked against embedded keys. /keys/ is the stable URL it will occupy.
• Importers for existing history from other tools — not started.
• A public witness network — the witness works, on one machine; a separately operated one is not provisioned.

Not in the first release

No accounts or hosted service. No dashboard. No enforcement — a scope violation is recorded, not blocked. No evals or scoring. No compliance framing. No generated summaries.