Block open-sourced Berd, a desktop app for AI agents built on Goose

Block, the parent of Square and Cash App, has open-sourced Berd, a desktop application for working with AI agents. The repository is built on Tauri 2 and React 19 and talks to the Goose agent backend through a WebSocket served by a bundled goose serve sidecar. It has gained 868 stars in its first thirty days on GitHub.

What is in the public build

The default build is a general-purpose distribution of a Goose-backed agent client with no private components. The Goose backend is pinned by a lockfile in the repository, and the build tooling downloads and stages the matching binary as an external Tauri sidecar. A local override is available for developers who want to run a Goose binary they have built themselves. The public app is self-contained and needs no private package registries or enterprise credentials.

The split between public and private builds

The interesting design choice is a clear split point for enterprise variants. A downstream organisation can build a private distribution by supplying managed provider settings, private resources, an optional companion command-line tool, its own update channel, and its own signing and publishing infrastructure. None of that is in the public source. The public app has a slot for an optional companion CLI as a Tauri app resource, and enterprise distributors provide that tool in their own build orchestration. The intent is that the public Berd and a private enterprise Berd share the same build system and validation flow without the private material entering the open repository.

Agent skills, published separately

Berd publishes portable Agent Skills under a top-level skills folder that can be installed independently of the app. Those are separate from the contributor workflows and from the starter skills bundled inside the distribution. The first published skill, buzz-handoff, pulls a Buzz channel or thread into a private agent conversation and can send an approved reply back through the public Buzz command-line tool.

Experimental features and how they are switched on

The app treats unstable UI and workflow behaviour as user-local experiments. Untouched experiments follow a global auto-enable setting that defaults on in development builds and off in production. The repository documents the storage rules, the registry contract, the Tauri safety rules, and the required test coverage in its experimental-features skill.

No outside pull requests

The contribution model is unusual for an open-source repository at this level of visibility. Outside pull requests are closed automatically, and only authorised repository collaborators can merge changes. The stated preference is a well-formed issue with a reproducible bug report. The rationale is that a bug the maintainers can reproduce is the part they cannot do themselves.

A team that wants a native desktop client for its own agent stack now has a real reference codebase with two useful properties. The build system already knows how to pin, stage, and update an external backend binary through a lockfile, and the private and public code are split at a defined point in the build rather than by a fork. That is a workable answer to the recurring question of how an enterprise releases a client built on an open agent backend without forking the public code or publishing its private material in it. The trade-off is the closed-PR contribution model, which means bug fixes from the outside have to go through the issue tracker rather than through a patch, and the close dependency on Goose, which any team that adopts it also takes on.

Source

Primary source: block/berd on GitHub.