Coding agents can now produce more code in an afternoon than anyone can carefully read, and the tooling around them has not kept up. They run loose in the working tree you are also using, or behind a web UI far from the repository they are editing; you are married to whichever vendor's CLI you happened to open; and the review that should decide whether any of it is good happens somewhere else entirely, in a browser tab, against a diff with no trace back to the conversation that produced it.
Crowbar is a local-first desktop IDE built around that gap. Import a repository and every branch becomes its own managed git worktree; start a chat and an agent goes to work inside one, in a real terminal you can watch and type into. Move that same conversation between Claude Code and Codex whenever one suits the task better. When it stops, the branch's review is already there — diff, inline comment threads, PR status — and nothing it did ever touched your own checkout. It runs entirely on your machine: one Go daemon, a React frontend, and a Tauri shell around them.
What's in this repo
Everything. api/ is the Go daemon that owns worktrees, agent sessions, terminals, LSP and search; web/ is the React frontend; desktop/ is the Tauri shell that hosts it; docker/ is the same daemon serving a prebuilt bundle for self-hosting. The daemon is the product — the desktop app is a window onto it, which is why the Docker image serves the identical thing with no desktop app involved.
What it does
- Diff review — every branch carries its own diff, inline comment threads and PR status.
- Provider switching mid-conversation — move a live chat between Claude Code and Codex freely.
- Deterministic workflows (WIP) — repeatable, declaratively-defined agent runs.
- And more yet to come.
Switch providers mid-conversation
Claude Code and Codex both run as first-class providers, and a chat is not bound to whichever one opened it. Switch mid-conversation and the outgoing CLI is asked to exit cleanly — so it flushes its own transcript instead of losing its last turn — while the incoming one picks the thread up in the same workspace. Providers can be enabled, disabled and prioritised globally, and each one reports whether it is actually installed on this machine.
That is possible because a provider is a YAML descriptor, not an integration. Everything Crowbar needs to know about a CLI — how to spawn it, how to resume a session, which hooks report progress — is declared in one file. The complete shipped Claude and Codex descriptors show the current format.
To add a provider, start with a descriptor for a compatible CLI, give it a unique id and display_name, and upload the YAML file in Settings → Agents. Crowbar checks the manifest before saving it under its home directory's descriptors/ folder. Install and log in to the CLI separately; the provider list reports whether its command is available. Existing provider IDs cannot be replaced by upload. You can check a file before uploading with cd api && go run -tags noEmbed ./cmd/crowbar descriptor validate /path/to/provider.yaml. Descriptor schema 0: pre-release, may change without migration. Each schema_version is read by its own reader into one internal model, so a later schema 1 is added beside schema 0 without changing it (see api/internal/engine/agents/internal/protocol/internal/descriptor/version.go). A file that states another schema_version, or no longer matches the shipped descriptors' shape, is not run: Settings → Agents lists it as Blocked with its line and the fix, an override of a shipped provider falls back to the shipped one, and Crowbar never moves or rewrites the file. .refused and .schema<N>.bak files an earlier development build left in descriptors/ are ignored; delete them or rename them back by hand.
Claude Code and Codex are the two descriptors proven end to end today. Static validation checks a user descriptor's structure and safety rules; behavior against its CLI depends on the manifest and that CLI.
Diff review
Every branch carries its own review: the diff, inline comment threads anchored to lines, and PR status — in the same window as the agent that wrote the code. Reading the work and going back to the agent about it is one motion instead of two tools and a browser tab.
Deterministic workflows (WIP)
Not every task deserves a conversation. Workflows are declaratively-defined agent runs — same steps, same order, every time — for the work you would otherwise re-explain in prose on each attempt. This one is in progress, not shipped.
Every branch is a worktree
Importing a repository provisions a managed worktree per branch, laid out by remote and branch name so the path tells you what it holds:
~/.crowbar/projects/<project>/github.com/acme/api/
├── main/worktree # protected → locked, provisioned at import
├── develop/worktree # protected → locked
└── feature/rate-limit/worktree
Protected branches are permanently checked out in their own locked worktree, so develop is always somewhere on disk in a known state. Everything else forks from origin's tip of its parent, not from whatever your local ref happens to be — a branch created at 9am does not silently start from yesterday's develop.
Agents only ever run inside a worktree. Two of them cannot tread on each other, and neither can reach the checkout you are working in.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
