get-bb/bb: an agentic IDE that drives itself from four different surfaces

What problem bb solves, and for whom

Most agent tooling today is a chat window bolted onto an editor. The agent runs, produces a diff, and the human copies it out. bb takes a different position: the agent should be able to control the tool it runs inside. The README states that bb "can control, customize, and automate itself, laying the groundwork for your own software factory." That is the pitch, and it shapes everything else in the repository.

The target user is someone who already runs an agent CLI such as Claude Code or Codex and wants more structure around it. bb does not ship its own model access. It uses the provider CLI you already have authenticated, which means your existing credentials and provider choice carry over. The topics list on the repository (ade, agent-ide, claude-code, codex, devtools, ide) matches that framing.

The second audience is people building automation on top of an agent rather than clicking through one. Because every surface is a first-class way to drive bb, a script can start a thread and a human can later open the desktop app and take over. That handoff model is the actual product claim, not the chat UI.

Threads, surfaces and the handoff model

The core unit of work in bb is a thread. The README describes work that "runs in threads you can follow live, steer at any point, or hand off to another agent." Three verbs, three different guarantees. Following is read-only observation. Steering means injecting direction while the agent is mid-run. Handing off means a second agent picks up the same thread rather than starting fresh.

The surfaces are the desktop app, the web app, the CLI, and an HTTP API. The README calls each of them a first-class way to drive bb, which is a stronger claim than "the CLI can talk to the same backend." It implies the API surface is not a second-class escape hatch bolted on for scripting.

Architecturally the repository shows a split that matters for anyone reading the source. There is a server, a host daemon, and the app. The development section is explicit that the app hot reloads itself while the server and the host daemon do not. That split explains the separate restart commands, and it tells you the daemon is a long-lived process holding state rather than something that restarts on every file save. The data directory differs by mode: development checkouts get `~/.bb-dev/<checkout-instance>/` with ports derived from the checkout path, while production runs use their own layout.

Installing bb and running your first thread

The README names the desktop app as the recommended starting point, downloaded from the desktop-latest release. It supports macOS on Apple Silicon (arm64). The Linux x64 AppImage is described as alpha, with the README asking users to expect problems and report them. Intel Mac users are told to use `npx` instead.

If you are not on Apple Silicon, the npx path is the general one. It starts the app and prints a local URL:

npx bb-app@latest

After it starts, open `http://localhost:38886`. To track the newest automated build rather than the stable release, the README gives the nightly tag:

npx bb-app@nightly

There is one install wrinkle worth reading before you run anything. npm 12 and later block dependency install scripts by default, and bb needs those scripts to build its native add-ons. The README lists the three packages involved: better-sqlite3, node-pty, and @parcel/watcher. You can allow them for a single invocation:

npx --allow-scripts=better-sqlite3,node-pty,@parcel/watcher bb-app@latest

Or set the policy once for all global installs:

npm config set allow-scripts=better-sqlite3,node-pty,@parcel/watcher --location=user

The second form is broader than the first. It changes the policy for every global install on the machine, not just bb. If you would rather not make that trade, use the per-invocation flag.

On Windows the README is blunt: install WSL2 first, then run the same npx command from your WSL2 shell. Native PowerShell and CMD are not supported. Node 22.19.0 or later is required according to the package.json engines field.

Telemetry, and why you should decide before the first run

Production runs, meaning the desktop app and `npx bb-app`, send anonymous usage telemetry. The README enumerates what is collected: app starts, thread creation counts, user message counts, and plugin installs. Identification is a random per-install id stored in your data dir. The README states that no user, host, project, workspace, or message content is attached.

There is a detail in the plugin section that is easy to miss and worth reading carefully. Plugin install events name only public plugins, meaning bundled plugins and entries from the `bb-community` marketplace. Installs from a local path, a private git or npm source, or a third-party marketplace report no name. That is a narrower disclosure than "plugin installs are counted" would suggest, and it is the kind of distinction that only shows up if you read the whole paragraph.

Development and source runs never send telemetry, and `BB_TELEMETRY=false` opts out of any run. The implementation lives in `apps/server/src/services/system/telemetry.ts` if you want to verify the claims against the code rather than the prose. This is a reasonable place to spend ten minutes before you point bb at a work repository.

Where bb is the wrong tool

The README carries a note that bb is in active development, with core architecture stable but workflows and surfaces still evolving. That is a candid statement and it should shape adoption. If you need a tool whose plugin API and CLI flags will not move under you, this is not it yet.

The platform matrix is the sharper limitation. Apple Silicon macOS is the supported desktop target. Linux x64 is alpha by the project's own description. Intel Macs and native Windows are not supported at all; Windows users go through WSL2. If your team is standardized on Windows laptops, bb is a WSL2 tool with the friction that implies, not a native one.

The remote access story has a security boundary that deserves attention. The README warns that the server API is unauthenticated and permits command execution and file reads. It repeats this warning for `pnpm dev:remote`, `pnpm start:worktree-remote`, and the storybook command. The guidance is to use these only behind a trusted network boundary and to restrict ports to Tailscale traffic with the host firewall when the LAN is not trusted. That is not a footnote. An unauthenticated API that executes commands is the whole risk model, and the README treats it as such.

Finally, bb is not a model provider. If you have no authenticated provider CLI, there is nothing for bb to drive.

How bb differs from Cursor and OpenCode

Cursor is the obvious comparison because people search for it alongside bb, and the difference is structural rather than a feature checklist. Cursor is an editor with AI features built into the editing surface. The agent lives inside the editor window, and the editor is the product. bb inverts that: the agent is the product, and the surfaces (desktop, web, CLI, HTTP) are ways to reach it. If your mental model is "my editor, with help," Cursor fits. If your model is "a thread of agent work I supervise and can automate," bb fits.

OpenCode is closer in spirit because it is also a CLI-driven agent. The distinction the README supports is breadth of surfaces and the self-modification claim. bb states that it can control, customize, and automate itself, and that every surface is first-class. A CLI-only agent gives you one driving surface; bb documents four, with the HTTP API available for automation.

Neither comparison is settled by the README alone. What the README does establish is that bb expects you to bring a provider CLI, so the provider question is separate from the IDE question. You are choosing the supervision layer, not the model.

Maintenance, licence and the upgrade path

The repository is not archived, and the last push was on 2026-09-20. The most recent release listed is desktop-v0.43.3 from 2026-09-18, with a nightly channel dated 2026-07-30. There is a desktop-latest release tag dated 2026-05-21, which suggests the stable pointer and the versioned releases move on different schedules. Anyone tracking bb should watch the versioned release rather than assume the latest tag reflects the newest code.

The licence is MIT, declared both in the repository metadata and in the root package.json. MIT is permissive: it allows commercial use, modification, and redistribution with the copyright notice retained. That is a statement about the licence text, not legal advice for your situation.

Upgrade cost is where the early-stage status shows. The desktop app has an auto-update feed, and the nightly build has a separate application identity, a yellow icon, and its own update feed, so the two can coexist. The README recommends nightly for early adopters, which is a reasonable way to describe a channel that may break. On the npx path, pinning is available through the version tags, but the README does not document a rollback procedure if an upgrade goes wrong. That gap is worth knowing about before you depend on bb for daily work.

Editorial conclusion

Adopt bb if you already have a provider CLI authenticated and want agent work to run in inspectable threads you can steer, with the option to drive the same session from a CLI or HTTP API later. Skip it if you are on Intel macOS, native Windows, or a Linux desktop you need to be stable, since the README calls the Linux x64 AppImage alpha. Before committing, verify three things: that your provider CLI is authenticated, that your npm version does not block the native add-on install scripts, and that you accept anonymous telemetry unless you set BB_TELEMETRY=false.

Frequently asked questions

Official sources

1. get-bb/bb on GitHub
2. License: MIT
3. Project website
4. README
5. Releases