openteams: a local-first workspace for Claude Code, Codex and 14 other coding agents

The problem openteams solves: relay work between terminals

The README opens with a scenario most people running coding agents will recognise. You start with Claude Code, add Codex, then Gemini CLI. Each one works fine alone. The cost appears between them: you repeat the same context, carry results from one window to another, and track who is changing what. The README states the failure mode plainly: you end up managing the agents instead of the work, with changes scattered across sessions and token usage disconnected from what shipped.

That framing sets the audience. openteams is aimed at indie developers who already have agent subscriptions or CLIs and do not want another model. The README is explicit that this is not a replacement for Claude Code, Codex or Gemini CLI. It is the layer around them. The README claims support for 16 coding agents, including Claude Code, Codex, Gemini CLI and the bundled openteams-cli. The topics list on the repository includes claude-code, codex, opencode and multi-agent-systems, which is consistent with that positioning.

The project is local-first and open source under Apache-2.0. The repository is not archived, and the last push was on 2026-09-09. The most recent release listed is a pre-release dated 2026-09-07, with two stable releases on 2026-09-01 and 2026-08-30. That release cadence is fast, and the pre-release naming scheme (v1.0.24-140.20260907133800) suggests automated builds rather than curated version numbers.

Who it is not for is equally clear. If you run one agent in one terminal, the shared session adds nothing. If you want agents to own the roadmap, the README says the opposite is the design: agents do the work, but they do not rewrite the plan.

One shared session, Git worktrees, and an issue list agents cannot rewrite

The mechanism has three visible parts in the README. First, a shared session where agents can talk, hand off work and keep the same context, replacing the pattern of relaying between terminals. Second, Workflow mode, which shows steps and dependencies before and during execution so a single step can be reviewed or retried without restarting everything. Third, isolated Git worktrees: when several sessions run at once, each can use its own worktree, so unfinished changes stay separate until you merge or discard them.

The repository layout backs the architecture. There is a crates/ workspace with server, db, executors, services, git, local-deployment, deployment and review members, plus a frontend/ directory and a src-tauri/ directory that is excluded from the Cargo workspace. The backend is Rust with axum and tokio, and the frontend is TypeScript. That split matters for anyone evaluating the project: the agent execution, Git handling and persistence live in Rust crates, not in the UI layer. A crates/review member suggests review is a first-class concern rather than a screen bolted onto a database.

The data flow the README describes is issues to sessions to build results. Issues hold the work you have chosen and link to the sessions where agents carry it out. Build statistics then report what was delivered alongside tokens and cost. The README contrasts this with the alternative in a small diagram: without openteams, three agents sit in three terminals and you relay; with openteams, they share a session and the plan lives in issues.

The design choice worth naming is that openteams does not try to give you more agents. The README says so directly. Everything in the product is coordination: sessions, worktrees, issues, statistics. If your problem is model quality, this project does not address it.

Installing openteams and running a first planned task

The README recommends the desktop app. It points to GitHub Releases and gives direct download links for three platforms: openteams-windows-x64.msi, openteams-macos.dmg and openteams-linux-amd64.deb. There is no Homebrew formula, no apt repository and no Docker image documented in the README, so the release downloads are the supported path.

On macOS there is a documented obstacle. The README states that the current macOS release is not signed or notarized by Apple. Because browsers add a quarantine attribute to downloaded apps, Gatekeeper may report that openteams is damaged even when the download is intact. The README begins to explain the workaround after dragging the app, but the excerpt ends there. If you are on macOS, read the full section on the documentation site before concluding the download failed.

There is also an npm package. The repository's package.json declares a bin entry named openteams pointing at npx/openteams-npx/bin/cli.js, and the README badge references the npm package openteams-web. The package.json is marked private, so the published artifact is the npx wrapper, not the repository root.

npx openteams

That command is the documented bin name from package.json. The README does not describe what the CLI does after launch, so treat this as a pointer to the npx wrapper rather than a complete workflow.

For development from source, the root package.json exposes a dev script and separate frontend and backend scripts. The backend uses Cargo, and the QA variant sets explicit ports and an allowed-origins variable:

pnpm install
pnpm run dev

The dev:qa script in package.json exports FRONTEND_PORT and BACKEND_PORT from scripts/setup-dev-environment.js and sets VK_ALLOWED_ORIGINS to the local frontend origin before starting both processes concurrently. That is the shape of a local two-process setup: a Rust backend on one port and a Vite-style frontend on another.

Where openteams gets in the way

The macOS signing gap is a real adoption cost, not a footnote. An unsigned, un-notarized build means every macOS user hits Gatekeeper on first launch, and the README itself anticipates the confusing "damaged" message. For a team distributing the app internally, that is friction on every upgrade unless someone documents the workaround.

The release naming is the second signal. The newest listed release is a pre-release with a timestamped version string, and the two before it are stable releases three and five days apart. Frequent automated releases are not a defect, but they mean you should check the release notes for the specific build you install rather than assuming the latest tag is the settled one.

Workflow mode is also a constraint as much as a feature. It shows steps and dependencies and lets you retry one step. That structure only pays off when the task decomposes cleanly. For exploratory work where you do not yet know the steps, the plan view is overhead, and a single agent in a single terminal will be faster. The README does not document rollback behaviour for a partially completed workflow, and it does not describe what happens to in-flight worktrees if the app is closed mid-run. Those are the questions to answer before putting a long task through it.

Finally, the local-first design means the record lives on your machine. The README does not describe sync, backup or multi-machine access. If you work across two computers, that is an open question the README leaves open.

openteams compared with running agents side by side by hand

The honest alternative is the setup the README starts from: several terminals, one agent each, and you as the message bus. That approach has real advantages. There is no extra process, no database, no app to keep updated, and no coupling to a release cadence. For a single task with one agent, it is strictly simpler.

The difference in approach is where state lives. In the terminal setup, the plan is in your head or in a notes file, context is pasted manually, and parallel changes collide in one working directory. In openteams, the plan is an issue list, the session is shared, and each parallel session can take its own Git worktree so changes do not overwrite each other. The README's own comparison table puts it as isolated worktrees you can review, merge or discard separately, against multiple agents changing the same workspace.

A second alternative is a general project-management tool with an agent integration. That gives you a hosted board, history and multi-user access, which openteams does not claim. What it does not give you is the shared session and the per-task worktree inside the same local app. If your coordination problem is mostly human, a hosted board is the better fit. If it is mostly agents stepping on each other in one repository, the worktree isolation is the part that matters.

The README frames the distinction as openteams not being a full project-management suite. Take that at face value: it is a workspace around your agents, with an issue list sized to that job.

Licence, maintenance and what an upgrade costs

openteams is licensed under Apache-2.0, and the repository carries a LICENSE file plus a CODE_OF_CONDUCT.md. Apache-2.0 permits commercial use and modification and includes a patent grant, which matters if you plan to build on the code rather than just run the app. It also requires that you preserve licence notices and state significant changes when redistributing. This is a description of the licence text, not legal advice; if you intend to redistribute a modified build, have counsel review it.

The bundled openteams-cli is part of the same repository, so the same licence covers it. The npm wrapper package is published separately; check its own metadata if you depend on it in a pipeline.

Maintenance is visible but fast-moving. The repository is not archived and the last push was on 2026-09-09. Three releases appear in the release list within roughly a week, one of them a pre-release. For an upgrade, that means reading release notes rather than assuming patch-level compatibility, and it means the desktop app is the primary distribution channel: the README points users at GitHub Releases rather than a package manager, so upgrades are manual downloads on all three platforms. There is no documented auto-update path in the README.

Running from source has its own cost. The backend is a Rust workspace with nine member crates, and the root package.json wires frontend lint, frontend tests, cargo clippy with qa-mode features, cargo fmt and cargo check into a single check script. Keeping a fork current means keeping that toolchain green. The Cargo.toml also patches tokio-tungstenite and tungstenite to forks, which is a dependency detail to be aware of if you vendor the workspace.

Editorial conclusion

Adopt openteams if you already run two or more coding agents and the coordination cost has become the bottleneck, and if you accept that the macOS build is unsigned and not notarized. Skip it if one agent in one terminal is enough, or if you want a hosted project-management suite rather than a local room around your CLI tools. Before committing, verify that the workflow templates match how you actually split work, and check the release notes for the platform you are on.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openteams-lab/openteams on GitHub
3. Project website
4. README
5. Releases