Install

Install Goobers, then watch it work

Get the binary running and watch a complete run finish — curate, implement, review, merge-preview — before spending a single token, connecting a repository, or touching a model credential.

Git 2.17 or newer is required, with git worktree add and git worktree remove available: every repo-backed stage runs in a fresh worktree, so the daemon needs both.

git clone https://github.com/Agent-Clubhouse/Goobers.git
cd Goobers
make build-goobers

git clone https://github.com/Agent-Clubhouse/Goobers.git
cd Goobers
npm --prefix portal ci --no-audit --no-fund
npm --prefix portal run build
go build -tags embed_portal -o bin\goobers.exe .\cmd\goobers
.\bin\goobers.exe --version

The pinned installer downloads only the assets attached to the release you name, verifies the archive against SHA256SUMS before extracting anything, and installs the binary to $HOME/.local/bin (override with GOOBERS_INSTALL_DIR). The versioned docs and onboarding payload land alongside it, under ~/.local/share/goobers/<version> — that copy, not this site, is your reference for the exact release you're running.

goobers version
goobers completion --help

goobers version confirms the binary you just installed is the one on PATH. Shell completion for bash, zsh, fish, and PowerShell is generated by goobers completion <shell>, if you want it.

The demo needs no repository, no provider credentials, no model spend, and makes no network writes. It runs entirely against mock providers.

goobers init --demo ./demo-instance
goobers run demo ./demo-instance

Keep the trailing path argument on both commands. run's default target is ., so calling it bare from outside ./demo-instance fails against the wrong instance rather than finding the demo automatically.

In a second terminal, open the operations portal against the same instance:

goobers dashboard ./demo-instance

dashboard serves the portal on localhost and blocks until you interrupt it. This is the first sight of the portal in this walkthrough, and it costs nothing: no daemon required, nothing running that could spend a credential.

The run moved through curate, implement, and review, passed an automated review-verdict gate, and produced a merge-preview artifact — the same shape a real run takes, with every stage mocked. A real run journal now sits on disk at demo-instance/gaggles/<gaggle>/runs/<run-id>/, readable with cat, jq, or the portal you just opened. Reading it is its own page.

macOS. A stage runs as a subprocess of the daemon, and inherits the daemon's PATH — not your interactive shell's dotfiles. Under a LaunchAgent that distinction is easy to miss: Homebrew installs to /opt/homebrew/bin on Apple silicon and /usr/local/bin on Intel, and a tool your shell finds fine can still be missing from a stage.

Windows. Native Windows cannot enforce the demo's network isolation, so init --demo fails closed there by design. Run the demo inside WSL 2 instead — goobers preflight checks the WSL 2 environment before you start. A repository with largeRepo: true on native Windows has its own host-tuning notes, linked from the product repo.

One SHA256SUMS manifest covers every published archive. macOS binaries are Developer ID signed and notarized; Windows binaries are Authenticode signed via Azure Trusted Signing and RFC 3161 timestamped. Neither replaces verifying the checksum — the signature proves who built it, the checksum proves you got exactly those bytes. There is no scoop or winget package yet: both identities are reserved upstream, pending a tagged release feed neither has today.