# bb: an IDE where your coding agents work together > bb is a free, open source, local-first IDE that runs coding agents in threads. Claude Code, Codex, Cursor and more, all programmable from one app. Author: [Flavio Copes](https://flaviocopes.com/about/) | Published: 2026-08-08 | Topics: [AI](https://flaviocopes.com/tags/ai/) | Canonical: https://flaviocopes.com/bb-agentic-ide/ I've been trying out [bb](https://getbb.app/), a new open source IDE built around coding agents. The tagline is "the IDE for loop-driven development". What that means in practice: you give tasks to agents, they run in parallel, and you check in on them when you want. bb is built by [Michael Yong](https://github.com/ymichael), who also created open-codex. It's MIT-licensed, local-first, and free. ## The problem it solves If you use coding agents every day, you know this pain. One agent fixed a bug in one terminal tab. You want another agent to review the fix, so you copy the diff into a different tool. A third agent finished an hour ago and is just sitting there, waiting for you to close it. The agents are good. The coordination between them is manual. Michael wrote about this in an essay called [The IDE Bottleneck](https://ymichael.com/2026/06/23/the-ide-bottleneck.html). His point: these workflows should be scriptable, but agent sessions are stuck inside apps designed for humans. Your Codex reviewer found problems with a PR, but your Claude Code agent can't see them unless someone (you) carries the message over. We have subagents, MCP servers, hooks, and skills. They let you program the work. But not the app around the work. bb is his answer to that. ## Everything is a thread In bb, work happens in **threads**. You type a task in the prompt box, pick an agent, and a thread starts. The thread shows up in your sidebar. You can follow it live, steer it mid-task, or hand it off to a different agent. Threads come in two kinds: - **standard** threads do the work directly - **manager** threads coordinate other threads A thread can own child threads. So you can have one agent spawn five workers, watch them, and collect their results. Agent-managing-agents is a first-class concept, not a hack. Each thread can run in its own [Git worktree](https://flaviocopes.com/git-worktrees/), so five agents can work on five branches of the same repo without stepping on each other. The homepage demo shows this: a thread triaging a Sentry spike gets its own `bb/triage-sentry-spike` worktree. The agent lineup is wide: Claude Code, Codex, Cursor, Pi, OpenCode, Grok, and more all live inside bb. You give a task to whichever fits. One detail I like: each agent runs on your existing subscription. You already pay Anthropic or OpenAI for the CLI. bb detects the provider CLIs you have authenticated and just runs them. There's no bb billing layer on top. ## How bb works under the hood bb is not a monolith. It's four pieces that talk over well-defined contracts. The **server** is the central hub. It stores all state in a SQLite database, exposes an HTTP API, and pushes change notifications over [WebSocket](https://flaviocopes.com/websockets/). The server itself is stateless: the database is the source of truth. The **host daemon** runs on each machine that executes work. It connects to the server, provisions workspaces, runs the agent provider processes, and posts progress events back. The **app** is the web UI. Sidebar, threads, prompt box. The **CLI** (`bb`) can do everything the app can do, but scriptable. The data model is small and makes sense once you see it: - a **project** maps to a repository, with one or more sources saying where the code lives - a **thread** is the unit of work, producing an append-only stream of events (messages, tool calls, file changes) - an **environment** binds a workspace directory to a host, and bb cleans up managed environments when no active thread uses them - a **host** is a machine enrolled to run work That last one matters more than it looks. A server has a primary host but can enroll **remote hosts** too. One project can map to paths on multiple machines, so you can drive work on your desktop from your laptop, or keep a beefy machine running agents while you carry something lighter. The separation is strict: the server doesn't know how workspaces get provisioned, and the daemon doesn't know what a thread or project is beyond the commands it receives. That's the kind of boundary that keeps a system understandable as it grows. ## The app itself is programmable This is the part that makes bb different from other agent orchestrators. There are three ways to use bb: - the **app**, for humans - the **CLI**, for agents - the **SDK**, for scripts They all drive the same core. Anything you can do by clicking in the app, an agent or a script can do through the CLI or SDK. This turns tedious coordination into normal programming problems: - turn an audit report into a batch of threads, one per finding - have one thread review another thread's work - broadcast "rebase against origin/main" to every stale thread at once My favorite example from Michael's essay: he asks threads to monitor CI, squash merge the PR when it's green, and archive themselves. The agent closes out its own session. He never has to. Think about that for a second. The most annoying part of running many agents is not the work. It's the babysitting. bb makes the babysitting a task you can delegate too. ## Change the IDE with a prompt Because agents can control bb, they can also extend it. Ask for a task tracker and one appears: a panel in your sidebar, a `bb tasks` command, and a skill that teaches every agent how to use it. This isn't a special demo feature. Many of bb's own features are plugins built with the same tools you have. The GitHub integration, agent memory, scheduled jobs, even remote access — all plugins. This is the same direction the whole ecosystem is moving. Cloud platforms now ship [plugins and skills for coding agents](https://flaviocopes.com/cloud-platform-plugins-ai-coding-agents/), and I maintain [my own small skill collection](https://flaviocopes.com/fstack/) for the same reason: teaching agents your workflow beats repeating it in every prompt. bb takes the idea one step further by making the IDE itself the thing you extend. If you've ever wished your IDE had some specific panel or workflow, this is a very different way to get it. You don't wait for a release. You describe it. ## Anything can kick off work The CLI that agents use is open to any program you write. A shell script can spawn a thread. A [cron job](https://flaviocopes.com/cron-job-nodejs-app/) can spawn a thread. A bot in Telegram, Signal, or Slack can spawn a thread. So you can message your bot "fix the failing CI on main" from your phone, and a worker thread starts on your machine. When you're back at your desk, the thread is waiting in your sidebar with the work done (or with questions). You can also schedule automations: point one at your issue tracker and it kicks off a thread for every new issue, or run nightly docs updates, changelogs, and error triage. All of this runs on your machine, not someone else's cloud. ## Try it The quickest way is npx: ```bash npx bb-app@latest ``` Then open `http://localhost:38886`. There's also a [desktop app](https://github.com/get-bb/bb/releases/tag/desktop-latest) built with [Electron](https://flaviocopes.com/electron/), currently macOS Apple Silicon only. Intel Macs and Linux use the npx route. On Windows, run the npx command inside WSL2. bb uses the provider CLIs you already have authenticated, so if Claude Code or Codex works in your terminal, it works in bb. Two things worth knowing before you install: - production runs send anonymous usage telemetry (app starts and thread counts, no content). You can opt out with `BB_TELEMETRY=false` - bb uses native Node.js modules like better-sqlite3, so if you have `ignore-scripts=true` in your `.npmrc`, run it with `npm_config_ignore_scripts=false npx bb-app@latest` The project is young (the repo was created in February 2026) and the README is upfront about it: core architecture is stable, workflows and surfaces are still evolving. ## My take The core idea here is strong: the app you use to manage agents should itself be usable by agents. Most orchestrators let you program the work. bb lets you program the workflow around the work — reviewing, merging, cleaning up, checking in. That's where my time actually goes these days. The project's vision doc says it well: users and agents are both first-class operators. I think that's the right bet. Agents are becoming another kind of user, and tools that treat them that way will win. It's open source, it costs nothing to try, and the [repo](https://github.com/get-bb/bb) is worth a look even just for the architecture. If some of the foundations here are new to you, I have free courses on [Git](https://flaviocopes.com/courses/git/) (worktrees and branches are exactly what bb leans on) and the [command line](https://flaviocopes.com/courses/terminal/). And working with agents like this — parallel threads, automations, agents managing agents — is exactly the kind of workflow we explore in the [AI Workshop](https://aiworkshop.sh) and in [Ship Lab](https://flaviocopes.com/courses/ship-lab/).