Skip to content

FAQ · PRIVACY AND BUZZ

Privacy, safety and Buzz

Does Berd send my data anywhere?

Berd itself sends one thing, and only if you switch it on: anonymous usage events tied to a random installation id, off by default in official builds. Everything else leaves your laptop because you connected something — a model provider, an OAuth connection, an MCP extension, a cloud voice engine, an update check — and each is a decision you can see in Settings.

Why this comes up: A desktop app that talks to AI models feels like a cloud service. It is not: sessions, agents, skills and memory are files on your disk. But the app is where the decisions that do send data get made, quickly.

What to do:

  1. Know the list. Every chat message goes to the provider of the model you chose. A connection acts through the service you signed into. Cloud voice sends speech to OpenAI; Local voice stays on the device. The updater checks a GitHub feed. Another harness brings its own sign-in and back-end.
  2. Decide the material before the tool. Client material needs a provider agreement that covers it; see Buzz or Berd.
  3. Leave telemetry off if in doubt; see the usage-data toggle.
  4. Attach logs to a bug report only on purpose; they exclude prompts, responses and session content.
  5. Know your build. A fork may change any of this.

Why it matters: Berd swaps the relay operator for the AI provider and the laptop itself. Neither is automatically safer. See What stays on your laptop.

Can Berd read my Buzz channels?

Only through the Buzz Handoff skill, only if the Buzz command-line client is installed and configured in the agent's environment, and only for a thread or channel you paste into the chat. Without the skill, a Berd agent does not know Buzz exists.

Why this comes up: Berd publishes buzz-handoff as its first public Agent Skill, and Morgan's Home canvas on On The Block had a Buzz project beside Berd's own. People conclude the two are integrated; they are separate products joined by one narrow route.

What to do:

  1. Install the skill from the repository's skills/ folder for the agent you will use.
  2. Configure the Buzz CLI outside the chat: buzz on the path, a relay URL and a private key in the agent's environment. The skill checks the variables exist and never prints them; it refuses Buzz Desktop's keychain and any key pasted into the conversation.
  3. Paste a buzz://message link or a channel id. The agent reads through the CLI, treats the content as untrusted, summarises what is relevant, and carries on privately.
  4. Sending anything back needs explicit approval of the exact text, channel and target; see Hand work between Berd and Buzz.
  5. This is read from the skill's contract at v0.6.4, not tested end to end.

Why it matters: The key you configure is the identity any reply carries; use a distinct agent identity if it should not look like you. See Start alone, then go multiplayer.

Should this work go in Berd or Buzz?

If nobody else needs to see it, add to it, or point back at it later, Berd. The moment one of those becomes true, Buzz. Decide before you start, because moving work later means building it again.

Why this comes up: Block describes the pair as "start alone, then go multiplayer," and most people use both in the same week. The question is which one for this piece of work now — and the third test, "point back at it later," is the one that catches people out.

What to do:

  1. Reading source material, drafting, building an agent or skill around your own way of working: Berd.
  2. Anything a client or colleague sees; anything you may need to account for later; anything you might hand over partway: Buzz.
  3. Decide the material first. In Buzz, whoever runs the relay can read everything; in Berd, the material sits on your laptop and goes to your provider.
  4. If unsure whether other people will get involved, start in Buzz. A quiet channel costs little; redoing the work costs a lot.
  5. Where the two meet, use the one route that exists; see Can Berd read my Buzz channels?

Why it matters: The common mistake is doing real work in Berd because it is quicker, then finding at handover that weeks of reasoning exist only in one person's chat history. The decision table is on Buzz or Berd; background in Start alone, then go multiplayer.

Why can't I edit a company-managed connection?

Because it was provisioned centrally, not by you. Company-managed connections are matched against Berd's catalog, shown in their own group in the connections section of Settings, and not freely editable or deletable the way your own extension is. Seeing that group at all tells you something: public releases compile managed connections off, so you are on an enterprise distribution, and the person to ask is whoever manages it.

Why this comes up: Connections and extensions share one settings surface. A connection is an OAuth sign-in to a catalog service; an extension is a tool you configure yourself. They look alike, and only one is yours to change.

What to do:

  1. Read the group and the status. Company managed is not yours to edit; Local is. Expiring or expired is not disconnected — use Extend access or Reconnect rather than starting over.
  2. For a change, go to your organisation's admin. Brad, Block's AI lead, on On The Block called this the point: a central team manages the knobs so employees do not have to.
  3. Add your own things as local extensions, which stay yours.
  4. Expect the same in Settings → security: on a managed install the protections may be marked as managed by your organisation.

Why it matters: An OAuth grant gives an agent standing access to Slack, GitHub or Drive. Central management lets a practice lead say what agents may reach; not changing it locally is the feature. See Connections, extensions and who manages them.

How do I move Berd to a new laptop?

Copy the two trees that hold your method — ~/.agents/ for agents and skills, and ~/.config/goose/ for the hints file and memory — plus any project-local .agents/ folders; export the sessions you need one at a time; re-enter your provider credentials. Beyond that the sources stop: nothing describes where the session database lives, whether it is portable, or how to carry the Home layout and settings across, and this Coach will not guess.

Why this comes up: Everything is a file, so a whole-install move sounds like a copy. It is, for the documented parts. The rest is the largest gap in the corpus until someone tries it.

What to do:

  1. Back up ~/.agents/ and ~/.config/goose/ with your dotfiles, today, not on moving day.
  2. Export sessions you may need to cite: Session History has an export per session, and an import that gives you a command to run, then a refresh. The export format is not described.
  3. Reconnect providers on the new machine; the credential store is not documented as portable.
  4. Expect to rebuild Home and re-check Settings by hand.
  5. Treat the old disk as still holding client material until it is wiped.

Why it matters: A lost laptop is a lost cast, a lost method and, if memory was in use, a lost record of how you like to work. Ten minutes of dotfile backup covers the documented part. See Know where your Berd lives, and back it up.

Can I contribute a fix?

Not as a pull request. Berd does not accept pull requests from outside authorised repository collaborators; an outside PR is closed automatically with a pointer to the contributing guide. What Block asks for instead is a well-formed issue, and it says plainly that a reproducible bug report is worth more to it right now than a patch.

Why this comes up: The source is public and Apache 2.0 licensed, which usually means contributions are welcome. The team's reason is stated: the architecture changes weekly, and reviewing outside patches against it costs more than it saves.

What to do:

  1. File through the issue forms — bug report or feature request. They require: search first, reproduce on the latest release, one issue per issue, exact version and OS, a scrubbed log excerpt.
  2. Let an agent help write it; the guide encourages it and supplies the prompt. You remain the author, and the agent must not invent details — "unknown" beats a guess.
  3. For a security vulnerability, never open a public issue; the repository's security policy describes private disclosure.
  4. Fork and build freely if you need a change today; building locally is also the best way to write a good report.
  5. If the policy changes, it will change in the contributing guide first.

Why it matters: For a consultant, the useful contribution is a clean report from real use, which is exactly what the team says it cannot produce itself. See Keep Berd current and report problems.

Last checked: Berd v0.6.4, 2026-09-11.

Reference

Verified
Berd v0.6.4 · 2026-09-11
NEVER BESTUCK AGAINCLICK ME

Guide built with Berd, Claude and Codex · verified against Berd v0.6.4, 2026-09-11 · read from source, not yet tested in the app · Buzz Guide · About · not affiliated with Block