Berd: a Tauri desktop client for the Goose agent backend

The problem Berd solves, and who it is actually for

Running an agent on your laptop normally means managing two things at once: the model backend and the interface you talk to it through. Berd collapses that into one desktop application. According to the README, it is "an open-source desktop app for working with AI agents," and it talks to the upstream Goose backend through the ACP WebSocket served by a goose serve sidecar. The app is the client; Goose is the engine.

The repository describes two audiences. The first is individual users who want a general-purpose public distribution: install it, run it, point it at providers. The second is organizations that need their own build. The README states that organizations "can also create enterprise distributions by supplying managed provider settings, private resources, and release infrastructure through the repository's distribution seams without adding private material to the public source tree." That second audience explains a lot of the repository's shape. There are directories such as distro/, release-agents/, and skills/ that exist to be extended or replaced, not just consumed.

If you are looking for a library to embed in your own product, Berd is the wrong layer. It is an application, and its extension points are build-time distribution seams rather than a stable public API surface.

How the Tauri shell, the sidecar and the lockfile fit together

The architecture is a three-part chain. The Tauri 2 shell hosts a React 19 frontend. The shell spawns a Goose backend as an external sidecar. The frontend reaches that backend over the ACP WebSocket.

The sidecar is not resolved at runtime by searching your PATH. It is pinned. `goose-backend.lock.json` records the commit, and `just setup` prepares "the Goose backend pinned by `goose-backend.lock.json` in your platform cache directory." On the next run, `just dev` reuses that stamped binary and, per the README, "fails if the lockfile commit no longer matches the cached build." That failure is deliberate. It prevents a stale backend from silently serving a frontend that expects newer protocol behavior.

Bundling follows the same model. The README says `just bundle` stages the pinned managed Goose binary and then runs `pnpm tauri build`. Staging produces `src-tauri/binaries/goosed-<rust-host-triple>`, which matches the `"externalBin": ["binaries/goosed"]` entry in `src-tauri/tauri.conf.json`. Note the name difference: the lockfile and the build tooling refer to Goose, while the staged artifact is called `goosed`. The README does not explain that rename, so treat it as an artifact naming convention rather than a second backend.

There is one escape hatch. Setting `GOOSE_BIN=/path/to/goose` before `just dev` bypasses the managed pinned checkout, and the README calls this "an explicit local override." It is useful for testing a backend you built yourself. It also means you are no longer running the combination the project tests.

Installing Berd and running it for the first time

The README gives two commands for a fresh checkout. `just setup` installs pnpm dependencies, builds the vendored `@aaif/goose-sdk`, and prepares the pinned Goose backend in your platform cache directory. `just dev` then launches the Tauri dev app against that cached binary. If the lockfile commit has moved since the cache was built, `just dev` fails rather than continuing, so a lockfile bump in a branch means you need a sync step.

just setup
just dev

To bump the default backend, the README shows a two-step flow: update the lockfile, then fetch and build the new pinned commit.

scripts/update-goose-backend-lock.sh main # or a tag/branch/sha
just goose-sync                          # fetch/build the new pinned commit

Building a distributable uses the same pinned staging step before the Tauri build:

just bundle

If you already have a Goose binary and want to test against it instead of the pinned one, the README documents a single environment variable override. This is the fastest path to a first real session, and also the path with the least support.

GOOSE_BIN=/path/to/goose just dev

For staging a specific binary without a full bundle, the README gives `GOOSE_BIN=/path/to/goose just stage-sidecar`. Windows is handled separately: the justfile exposes `setup-windows`, `dev-windows` and `tauri-check-windows`, which call PowerShell scripts under `scripts/windows/`. The justfile notes that fresh Windows machines need `winget install --id Casey.Just -e` before those entrypoints exist.

What you give up: no outside pull requests

The participation model is the sharpest constraint here, and the README is unusually direct about it. Berd is built in the open, and you can read, build and fork the source, but the project states that it does not accept pull requests from outside authorized repository collaborators, and that outside PRs are closed automatically.

The sanctioned channel is an issue. The README argues that "a bug report we can reproduce is worth more to us than a patch, because it's the part we can't do ourselves," and points to CONTRIBUTING.md and the issue forms for the required detail. That is a coherent position for a small team, and it does reduce review load. It also means a fix you write stays in your fork until someone inside Block reproduces and lands it. If your organization's contribution policy requires upstreaming patches, Berd cannot satisfy it.

Two smaller limitations are worth naming. First, the README does not document rollback for a backend bump: the lockfile update flow moves forward, and there is no described procedure for reverting a pinned commit after it has been staged. Second, experiments are described as "user-local preferences for unstable UI or workflow behavior," with the global auto-enable setting defaulting on in dev builds and off in production builds. Anything you build on top of an experiment is building on something the project labels unstable.

Enterprise distributions and the seam that is not a plugin API

The distribution seams deserve a clear-eyed reading. The README says enterprise distributors "may overlay private agents, runtime configuration, optional companion tools, update channels, and signing or publishing infrastructure in their own private build orchestration." There is also a documented seam for an optional companion CLI, which is bundled as an app resource. The public app does not require a private CLI package; distributors provide and package their own implementation "while retaining the normal Berd build and validation flow."

That is a build-time contract, not a runtime plugin system. Nothing in the README describes a stable API that third-party code can call into without forking the build. An enterprise adopting Berd this way is maintaining a private build pipeline that tracks the public tree, and the lockfile discipline that keeps the backend pinned applies to their overlay too.

The public build is described as self-contained: no private package registries and no enterprise credentials are required. That is a real advantage for evaluation, because you can reproduce the default distribution without any account.

Agent skills that work without the app

Berd publishes portable Agent Skills under `skills/`, and the README states these "can be installed independently of the Berd app." That independence is the interesting part. The skills directory is separate from the contributor workflows under `.agents/skills/` and from the starter skills bundled under `distro/skills/`, so there are three distinct skill locations with three different purposes, and the README only describes one of them as portable.

The first published skill is `buzz-handoff`. Per the README, it "brings Buzz channel or thread context into a private agent conversation and can send an explicitly approved reply through the public Buzz CLI." The approval step is explicit in the description, which suggests the design keeps sending as a deliberate action rather than an automatic side effect. The README does not document the Buzz CLI's installation or authentication, so if that skill is your reason for looking at this repository, the surrounding setup is not described here.

Compared with a general-purpose agent framework, the difference is scope. A framework gives you primitives to assemble a workflow. Berd gives you a finished desktop client plus a small set of named skills, one of which is published.

Alternatives and the difference in approach

The most direct alternative is running Goose yourself and skipping Berd entirely. Goose is the backend Berd talks to, and the README treats it as an upstream project pinned by commit. If you are comfortable with a terminal and a WebSocket endpoint, you get the same agent with none of the desktop packaging, and you avoid the lockfile sync step. The cost is that you build your own interface and your own update path.

A second alternative is any desktop chat client that connects to a model provider directly. Those clients own the whole stack: the model call happens inside the app. Berd does not do that. It delegates to Goose through the sidecar, which is why the backend is pinned and why a version mismatch is a hard failure rather than a degraded experience. If you want a single binary with no external process, Berd's architecture is working against you.

A third path is forking Berd. The licence permits it and the README encourages reading and forking. But a fork inherits the pinning discipline and the distribution seams, and it does not inherit upstream fixes automatically, since outside pull requests are not merged. That trade is worth pricing before you start.

Editorial conclusion

Adopt Berd if you want a desktop shell around Goose and you are willing to track a pinned backend commit through goose-backend.lock.json, or if you are an enterprise distributor who can use its distribution seams for private providers and signing. Do not adopt it expecting to upstream patches: the README states that outside pull requests are closed automatically, so the only participation channel is a well-formed issue. Before committing, verify that the platform you build on has a working path in the justfile, since the Windows flow runs through separate PowerShell scripts, and check whether the public build's defaults for experiments match what you want in production.

Frequently asked questions

Official sources

1. block/berd on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases