Show HN: bb, an agentic IDE that can control itself

Developer ymichael released bb, an agentic IDE that allows users to orchestrate coding agents together and control them programmatically via web app, CLI, and HTTP API. The tool is in active development with a stable core architecture, and the desktop app is available for macOS Apple Silicon, with other platforms supported via npx.

bb is an agentic IDE that can control itself. You can seamlessly orchestrate all of your favorite coding agents together and have them programmatically use bb too. Every surface — the web app, CLI, and HTTP API — is a first-class way to drive bb. Work runs in threads you can follow live, steer at any point, or hand off to another agent. Note bb is in active development. Core architecture is stable, but workflows and surfaces are still evolving. The recommended way to start using bb is the desktop app: Download the latest desktop app https://github.com/ymichael/bb/releases/tag/desktop-latest The desktop build is currently macOS Apple Silicon arm64 only. Intel Mac, Linux, and Windows users should run bb with npx instead. npx bb-app@latest Then open http://localhost:38886 . bb uses the provider CLI you already have authenticated. For install requirements, provider setup, configuration, and package-focused docs, start with packages/bb-app /ymichael/bb/blob/main/packages/bb-app/README.md . Production runs the desktop app and npx bb-app send anonymous usage telemetry app starts and thread creation counts to help us understand adoption. Identification is a random per-install id stored in your data dir — no user, host, project, or workspace data is ever attached. Development/source runs never send. Opt out any run with BB TELEMETRY=false . See apps/server/src/services/system/telemetry.ts /ymichael/bb/blob/main/apps/server/src/services/system/telemetry.ts . This monorepo contains the packaged app plus the runtime services it bundles: | Package or app | Role | |---|---| packages/bb-app | npx bb-app@latest launcher. apps/app apps/server apps/host-daemon apps/cli bb CLI for users and agents. apps/landing packages/server-contract packages/host-daemon-contract Use the development loop when working on bb itself: pnpm dev That starts the Vite app and proxies API and WebSocket traffic to a separate dev server. The launcher prints the actual ports at startup. Each checkout gets a data directory under ~/.bb-dev/<checkout-instance / and deterministic high ports derived from the checkout path. The checkout instance id is the sanitized path to the checkout, relative to your home directory, plus a short hash suffix. Separate worktrees can run alongside each other and the packaged npx bb-app@latest instance. To use the dev app from another machine, for example over Tailscale, run: pnpm dev Then open http://<remote-host-or-tailscale-ip :<app-port . Source dev binds the browser app to all interfaces and uses the browser host for WebSockets by default. To use the component storybook from another machine, run: pnpm storybook Ladle also binds to all interfaces and configures its HMR WebSocket to use the browser's current host instead of localhost . Development behavior is intentionally split: - the app hot reloads itself - the server does not hot reload - the host daemon does not hot reload When you want the server and host daemon to pick up the latest build output, use: pnpm dev:restart pnpm dev:restart-server pnpm dev:restart-host-daemon These rebuild first, then restart only the targeted stateful services. To test the release-style package launcher from a source checkout: pnpm start That builds the local bb-app package artifacts and runs packages/bb-app/dist/bb-app.js , matching the published npx bb-app@latest path without downloading from npm. pnpm bb --help built CLI, targets the default/prod instance pnpm reset clear production state pnpm bb:dev --help source CLI, targets this checkout's dev instance pnpm reset:dev clear this checkout's dev state pnpm reset:all clear both production and dev states These reset commands prompt for confirmation before deleting anything. | Component | Role | |---|---| Server | Central hub. Stores all state in a SQLite database, exposes an HTTP API, and pushes change notifications over WebSocket. Stateless itself — the DB is the source of truth. Routes work to hosts by queuing commands. | Host daemon | Runs on the local machine. Connects to the server, picks up commands, provisions workspaces, runs agent provider processes, and streams events back. Exposes a local HTTP API for the app and CLI to do machine-local things open editor, pick folders, check daemon status . | App | Web UI for inspecting projects and threads, following progress, and steering work. | CLI bb | First-class interface for both users and agents. Same capabilities as the app, scriptable. | The core entities and how they relate: Project — the top-level container, usually mapped to a repository. A project has one or more sources that say where its code lives. Sources retain a host ID boundary, but supported project sources currently point at the primary local host. Thread — the unit of work. Each thread tracks a conversation with an agent provider, has lifecycle state, and produces an append-only stream of events messages, tool calls, file changes, etc. . Threads can be standard does work directly or manager coordinates other threads . Threads can own child threads for delegation. Environment — the execution context for a thread. It binds a workspace a directory on disk to a host. An environment can be unmanaged point at an existing directory , or managed . Environments managed by bb will be cleaned up when there are no longer any unarchived threads using it. Multiple threads can share an environment. Host — a long-lived daemon identity for the machine that runs work. bb currently supports one primary local host; the host boundary remains in the data model for future expansion. Commands and events — the server talks to daemons by queuing commands provision an environment, start a thread, stop a thread . Daemons report back by posting events. This is an asynchronous command/event protocol — the server queues work, the daemon picks it up, results flow back as events. Two contract packages define the boundaries between components: @bb/server-contract — the HTTP + WebSocket API between clients app, CLI and the server. Route schemas, request/response types, WebSocket notification types. @bb/host-daemon-contract — the protocol between the server and host daemons. Command types, event types, session lifecycle, the local API for app/CLI. Implementation packages never import across these boundaries. The server doesn't know how workspaces are provisioned. The daemon doesn't know about threads or projects beyond what commands tell it. The most useful contributions are feature requests and bug reports. If you run into something broken, confusing, or missing, open an issue with the workflow you were trying to accomplish and what happened instead.