conductor-oss

What Conductor is

Conductor OSS is a local first control surface that sits between your repositories and the coding CLIs you already use. The README lists what it is: a dashboard for linked workspaces and running sessions, a launcher for supported coding agent CLIs, a git worktree manager so concurrent sessions do not stomp on each other, a session runtime with real first party PTYs, a local state layer backed by SQLite, and an optional paired device bridge for reaching your own machine remotely. Just as important is the list of what it is not. It is not a replacement model provider, not a hosted cloud IDE that stores your code by default, not a fake browser chat wrapper around terminal output, and not dependent on one agent vendor. The README is blunt that new repositories use each agent's normal permission behavior, which may include approval prompts or an agent provided sandbox; Conductor manages worktrees to separate concurrent Git changes, but it does not promise operating system isolation. The optional automatic permission mode is called an explicit trust decision for workspaces where broad local execution is acceptable. That framing sets honest expectations about safety boundaries. The source lives in the charannyk06-conductor-oss repository on GitHub and is implemented in Rust, with the license recorded as Apache-2.0 in the project metadata.

Local and paired device flows

The README stresses that there are two distinct ways to use Conductor, and mixing them causes confusion. The local dashboard runs on the same machine as your repos: you run the npm launcher, which defaults to co start --open, and if you pass no workspace it boots a default one under the user home directory. The second path is a hosted dashboard plus a paired device bridge, meant for opening Conductor from another browser, computer, or phone while the actual work stays on your machine. The install command for the bridge is a cURL or PowerShell script that connects to a relay. The README is explicit that the hosted dashboard is not a cloud IDE and that your repos, terminals, and agents remain on the paired machine. There is also a warning: if you only forward a local dashboard port from a remote VM, Conductor still treats that as remote access and blocks it unless you add an identity layer. For remote use the documented options are pairing with the hosted service or putting your self hosted dashboard behind Clerk or Cloudflare Access. The pairing model is the privacy preserving answer to wanting access from a phone without uploading code. The source lives in the charannyk06-conductor-oss repository on GitHub and is implemented in Rust, with the license recorded as Apache-2.0 in the project metadata.

CLI and supported agents

Most day to day work goes through a CLI with the co alias. The README's command table covers start, init, setup, spawn, list, status, send, feedback, retry, restore, kill, cleanup, doctor, dashboard, bridge setup, mcp-server, and acp-server. The init command scaffolds a conductor.yaml and a CONDUCTOR.md in a repo, while spawn starts a new agent session for a project. The agent picker shows whatever CLIs Conductor can discover on your machine, and the supported adapters include Claude Code, Codex, Gemini, Qwen Code, Amp, Hermes, Cursor CLI, OpenCode, Pi, Droid, GitHub Copilot, and CCR. Each agent runs in its real terminal UI rather than a simulated chat shell, so reconnects, resize, and mobile behavior act like a genuine terminal. The session detail page is built around four surfaces: a live Terminal PTY, an Overview with normalized state, a Preview of the dev server URL, and a Diff view of file changes. Markdown planning lives in CONDUCTOR.md with a task lifecycle from Inbox to Done, but you can skip the board and launch sessions directly. The ACP and MCP server modes let other clients drive Conductor over stdio, with preconditions around initializing the workspace first. The source lives in the charannyk06-conductor-oss repository on GitHub and is implemented in Rust, with the license recorded as Apache-2.0 in the project metadata.

Building from source

Developers who want to run Conductor from a checkout need a Rust stable toolchain, Bun 1.2 or newer, Node.js 20.9 or newer, and git. The install step is bun install for the workspace and the preview worker, and bun run dev:full brings up the full stack. Useful scripts include bun run dev for the dashboard only, bun run dev:backend for the backend through the launcher path, bun run build for a production build, bun run typecheck for TypeScript, and cargo test plus cargo clippy for the Rust side. The project structure shows a Rust workspace under crates, with separate packages for the CLI, core config and board parsing, the SQLite database, executors and process management, git and worktree operations, the relay server, the Axum server, shared types, and a filesystem watcher. On the web side there is an npm launcher, a shared core package, and a Next.js dashboard. The docs folder holds screenshots and deployment notes. The README also documents known constraints: output quality depends on the upstream agent CLI, GitHub heavy flows work best with gh installed, and preview tooling depends on a project exposing a local dev server. Public share link remote control without an identity layer is not supported, and legacy tmux data should be archived rather than treated as the live path.

Editorial conclusion

The project pairs a Rust backend with a Next.js dashboard, is published under the Apache-2.0 license, and runs from an npm launcher.