OpenTeams
A local-first AI desktop app that organizes Claude Code, Codex, Gemini CLI, and 13 other coding agents into a controllable team for planning, building, and shipping software.
Evidence shows architectural emphasis on isolated Git worktrees, step-level review/retry/skip, and ACP approval plus permission config (mentioned in changelog), which supports rollback and partially supports user_confirmation; however, the approval flow, permission model, and related UI implementations are absent from the provided files, so these are scored as assertions (1). least_privilege, data_flow_transparency, and sensitive_data_handling lack supporting docs or code; a CLI test shows access/refresh tokens stored in plaintext in local SQLite with no visible encryption or cleanup policy — a concrete deduction. dependency_security has a real weakness: Cargo.toml pins tokio-tungstenite/tungstenite to a third-party fork (openai-oss-forks) at fixed revs, and ts-rs is pulled from a personal fork (xazukx), a supply-chain risk with no audit or advisory notes. external_effects is deducted because the app launches external CLI agents and several agent installs use curl|bash pipe scripts, with risks not documented in any security doc. rollback earns 2: worktree review/merge/discard and per-step retry are concretely and consistently described in the README. source_attribution earns 2: full Apache-2.0 LICENSE, clear npm/GitHub provenance; deducted because the publisher is unverified and builds depend on private keys and undisclosed endpoints (VK_SHARED_API_BASE).
self_consistency is deducted: the README changelog tops out at v1.0.9 (2026-08-04) while package. says 1.0.24-140; two different Discord invite links (MbgNFJeWDc vs /openteams) appear in the same README, and changelog dates are in the future (2026), so version and link self-consistency is damaged — score 1. dependency_availability earns 2: CI workflows pin Node 22, pnpm 10.13.1, toolchain, cargo tool versions, with lockfiles and caching, showing strong reproducible-build intent; the nightly-2025-12-04 pin is a fragile point. failure_messages earns 1: only scattered troubleshooting notes (cargo-watch, Gatekeeper); no systematic error-handling or user-facing failure documentation.
audience_and_scenarios earns 3: the 'Who It Is For' section, is/is-not table, and concrete scenario descriptions are clear and honest. capability_boundaries earns 2: the is/is-not table explicitly disclaims being a model, a PM suite, or a black box, but limits (concurrency caps, budget behavior) are not quantified. trigger_precision earns 1: no AGENTS.md or trigger/scheduling spec; @-collaboration and Workflow triggering are only summarized. environment_fit earns 3: Windows/macOS/Linux/Web targets, Node/Rust/pnpm prerequisites, per-platform artifacts, and Windows troubleshooting are all documented with evidence.
information_architecture earns 2: README structure is complete (what/why/quick start/features/dev/contributing/license), but deeper docs live behind doc.openteams-lab.com links, leaving in-repo depth thin. install_notes earns 3: desktop install, npx, macOS unsigned-quarantine handling, local build, and Windows troubleshooting are all present — the strongest area in this review. naming_stability earns 2: 'openteams' is consistent overall, though 'OpenTeams CLI' vs 'openteams-cli' casing is mixed. examples_and_faq earns 1: only an ASCII diagram and screenshots; no runnable examples or FAQ. known_limitations earns 2: the unsigned/notarized macOS risk is explicitly disclosed with remediation and a 'do not disable Gatekeeper globally' caution — good practice; performance/security limits remain undisclosed. license earns 3: full Apache-2.0 text in LICENSE plus an accurate plain-language summary covering trademarks and patents. versioning_changelog earns 2: dated Major updates and a Roadmap exist, but the changelog stops at v1.0.9 while the package is at 1.0.24, and there is no CHANGELOG file. maintenance_responsibility earns 2: CONTRIBUTING, good-first-issue labels, multi-channel community, and active releases are visible; no explicit maintainer list or security-response channel (SECURITY.md not in evidence).
output_usability earns 1: deliverables (artifacts, diffs, transcripts, statistics) are README claims only; no supporting UI/data structures appear in the provided files. marginal_value earns 2: shared multi-agent sessions, worktree isolation, and cost statistics are a clear increment for the 'managing many coding agents' pain point with a specific differentiation narrative; deducted because core differentiators are not shown at the code level. cost_benefit earns 2: the value proposition ('transform token consumption into real productivity') with per-session/per-model cost breakdown is explicit; accuracy and local record format cannot be statically verified.
claim_traceability earns 1: key claims (approval flow, budget caps, reviewer-loop invariants, statistics accuracy) cannot be traced to implementations in the provided files; they appear only in changelog/README. cross_source_corroboration earns 1: CI workflows and package. mutually corroborate build/signing flow, but version numbers and Discord links contradict each other and changelog dates (2026) precede the package version — cross evidence is inconsistent. fact_inference_separation earns 2: the is/is-not table and the plain-language license summary cleanly separate factual statements from interpretive framing; deducted for marketing assertions ('Turn tokens into real productivity') presented without evidence.
- Cargo.toml uses [patch.crates-io] to point tokio-tungstenite/tungstenite at a third-party fork at fixed revs, and ts-rs at a personal fork; audit the fork provenance and diffs before adoption.
- The openteams-cli test shows account access/refresh tokens written in plaintext to local SQLite; verify disk encryption and token storage security before use.
- The macOS build is unsigned/un-notarized; only run the documented xattr quarantine-removal command if you trust the artifact source, and do not disable Gatekeeper globally.
- Several third-party agents are installed via curl | bash pipe scripts; review the scripts before executing them.
- README versions (max v1.0.9) conflict with package. (1.0.24-140), two Discord links differ, and changelog dates are in the future; rely on actual repository tags when evaluating.
- This is a static source review (low confidence) with no executed verification; key claims such as approval flow, budget caps, and statistics accuracy are unverified at runtime.
What does this agent do, and when should you use it?
OpenTeams (GitHub: openteams-lab/openteams) is an open-source, local-first AI desktop app whose pitch is 'plan, build, and ship with a team of AI agents instead of one.' It is not a new model; it is a workspace that puts your existing coding agents — 16 are supported, including Claude Code, Codex, Gemini CLI, and the bundled openteams-cli — into one shared session with unified context and explicit work handoffs. Developers keep control of direction through an owned Issue list that links work items to agent sessions, and agents never rewrite the roadmap. Workflow mode decomposes complex tasks into steps with dependencies, reviews, retries, and acceptance that you can inspect and re-run individually, while parallel sessions run in isolated Git worktrees. Built on a React/TypeScript frontend, Rust backend, and Tauri desktop shell, it keeps runtime records locally under .openteams/ and reports build statistics tying deliverables to token usage and cost. It is Apache-2.0 licensed and ships for Windows, macOS, Linux, and Web.
OpenTeams reads your configured local workspace and brings multiple coding agents (Claude Code, Codex, Gemini CLI, Qwen Code, OpenCode, Amp, GitHub Copilot, Cursor, Droid, Kimi Code, Qoder CLI, Pi, Hermes, Kiro CLI, DeepSeek Harness via ACP, plus the bundled openteams-cli) into a shared session where they work from the same conversation and project context. In Free Chat you invoke agents directly with @; in Workflow mode complex tasks become structured steps with dependencies, reviews, retries, and acceptance, viewable before and during execution, with per-node skip support. Parallel sessions each run in their own Git worktree so results can be reviewed, merged, or discarded independently. Issue management records and prioritizes developer-controlled work items, syncs issues from GitHub, and creates or links sessions for execution. Build statistics compare bugs fixed and features delivered against token usage and cost across sessions and models, and logs, diffs, transcripts, and artifacts stay attached to the work. Runtime records are kept under .openteams/.
- An indie developer running Claude Code, Codex, and Gemini CLI who is tired of juggling terminals and manually relaying context between windows
- A technical lead who needs agent runs to be reviewable and reproducible, with step-level retry instead of restarting an entire flow
- A team running multiple parallel tasks that wants each isolated in its own Git worktree before choosing to merge or discard
- A developer who wants to drive agent execution from a local, developer-controlled issue list synced from GitHub, keeping the roadmap in human hands
- A manager comparing deliverables against token and cost breakdowns per session and model to judge agent ROI
- A small team that wants ready-made team workflow templates to kick-start a plan-build-ship process
What are this agent's strengths and limitations?
- Multi-agent shared session with unified context replaces manual relaying between terminal windows
- Workflow mode exposes steps and dependencies with per-node review, skip, and retry — no black-box one-shot runs
- Each parallel session runs in its own Git worktree, so unfinished changes stay isolated until you merge or discard
- Developer-owned Issues link work to sessions, and build statistics tie deliverables to token usage and cost
- Supports 16 coding agents plus a bundled openteams-cli with no single-vendor lock-in; local-first with records kept in .openteams/
- The macOS build is unsigned and unnotarized, requiring a manual xattr command to pass Gatekeeper
- You must separately install and configure each external agent CLI (Claude Code, Codex, etc. each need a global install and their own model credentials)
- Building from source requires Rust, Node.js, and pnpm (plus cargo-watch on Windows in some cases)
- The project is under active development with a roadmap of undelivered capabilities (expert AI workers, deeper team composition); rapid releases (v1.0.9 dated 2026.08.04) may bring churn
- As a local desktop app it requires a local runtime and filesystem access, so it does not fit purely cloud-hosted workflows
How do you install or deploy this agent?
Recommended: download the latest release for your platform from GitHub Releases — openteams-windows-x64.msi for Windows, openteams.dmg for macOS, openteams-linux-amd64.deb for Linux. The macOS build is not signed or notarized; Gatekeeper may report it as 'damaged.' After dragging openteams.app to /Applications, and only if you trust the official GitHub Release, run: xattr -dr com.apple.quarantine /Applications/openteams.app. Alternatively run via npm: npx openteams-web. To build from source you need Rust >= 1.75, Node.js >= 18, and pnpm >= 8: git clone https://github.com/openteams-lab/openteams.git && cd openteams && pnpm i && npm run dev; build the desktop app with pnpm run desktop:build. To compile openteams-cli locally: bun run ./scripts/build-openteams-cli.ts. On Windows, if pnpm run dev reports 'error: no such command: watch', first run cargo install cargo-watch.
How do you use this agent?
After installing and launching, configure model providers under Settings → Provider Config → Add Provider (the built-in openteams CLI agent works out of the box). Then connect your existing coding agents, e.g.: npm i -g @anthropic-ai/claude-code (Claude Code), npm i -g @openai/codex (Codex), npm i -g @google/gemini-cli (Gemini CLI), npm i -g opencode-ai (OpenCode), npm i -g @qwen-code/qwen-code (Qwen Code), npm i -g @github/copilot (GitHub Copilot); Pi needs no install (runs via npx) and Hermes installs via pip install hermes-agent. In daily use: use @ in Free Chat for lightweight direct collaboration; switch complex tasks to Workflow mode to see steps and dependencies, reviewing, skipping, or retrying individual nodes; record and prioritize work in the Issue list, sync GitHub issues, and create or link sessions for execution; let parallel sessions use separate worktrees and review, merge, or discard each result; check build statistics for deliverables, tokens, and cost.
How does this agent compare with similar options?
The README explicitly contrasts OpenTeams with using Claude Code / Codex / Gemini CLI directly: standalone agents force you to relay context and results across terminal windows, while OpenTeams does not replace them — it adds a shared session, visible workflows, controlled issues, and cost statistics on top.