# Manaflow: a desktop cockpit for running several coding agents at once > An MIT licensed TypeScript, Python and Rust monorepo that spawns Claude Code, Codex CLI, Cursor CLI, Gemini CLI, Amp and Opencode in parallel, each inside its own VS Code workspace, and then gives you the diff view, terminal, web preview and pull request to check the work. **manaflow-ai/manaflow** — Open source Claude Code web/Codex Cloud/Devin/Ramp Inspect alternative - Repository: https://github.com/manaflow-ai/manaflow - Stars: 1,113 · Forks: 60 - Language: TypeScript - License: MIT - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/manaflow-ai-manaflow ## The product pitch is a grid of terminals you did not have to write The repository description names its competitors outright: an open source Claude Code web, Codex Cloud and Devin alternative. The README shortens that to parallel spawning of Claude Code, Codex CLI, Cursor CLI, Gemini CLI, Amp and Opencode, with the phrase and other coding agent CLIs covering whatever else a user drops in. The unit of work is a task. Each task gets an isolated VS Code workspace, either in the cloud or in a local Docker container, and the README states the reason plainly: so parallel agent work stays verifiable, fast and ready to ship. That word verifiable is doing the load-bearing work. Running six agents at once on your checkout is easy and almost always produces a mess you cannot review. Running six agents each in a disposable workspace, each with its own branch and its own dev server, is the version that survives contact with a real repository. So the interesting contribution is not the spawning. It is the review surface that comes after the spawning. One naming detail worth flagging before you search for anything else: the GitHub repository is Manaflow, the hosted service is manaflow.com, and every identifier inside the code is still `cmux`. `package.json` has name `cmux`, `pyproject.toml` has name `cmux`, and the environment template is headed cmux. The screenshot assets are still named `cmux0.png` through `cmux4.png`. Whatever this was called before, the rename is incomplete. ## Three languages in one monorepo, and what that costs GitHub reports TypeScript as the primary language, but the tree says otherwise in practice. There is an `apps/` directory for the web frontend, `packages/` for shared libraries, `crates/` for Rust, a Python package at the repository root, plus `prompts/`, `skills/`, `evals/` and `docs-ai/` directories. The Dockerfile explains why the Rust is there. It is a build stage that cross-compiles against a set of build ARGs pinned to specific toolchain versions: Node 24.9.0, Go 1.25.2, an NVM release, a Rust release, and Docker plus Compose, BuildKit and Buildx channels. It also takes `ARG IDE_PROVIDER=cmux-code`, which is the clearest single indicator that VS Code Server is being repackaged rather than merely launched. Pinning five toolchains in one file is what a serious distribution build looks like, and it is also what makes the project expensive to fork. What you get for that complexity is a desktop application rather than a script. There is a macOS direct download link, Linux marked as beta and Windows described as coming soon, which means for most Linux users the honest options are the beta or running from source. The Python side is small by comparison. The root `pyproject.toml` requires Python 3.11 or higher and depends on `cdp-use`, `morphcloud` and `requests`. The first two are the important clue: `cdp-use` is Chrome DevTools Protocol automation, which is how the VNC browser preview gets driven, and `morphcloud` is the sandbox provider SDK. So the Python layer is not a server. It is the code that talks to a remote sandbox and to a browser. ## Configuration tells you exactly what has to exist before it works The `.env.example` file is the most honest document in the repository, because it enumerates the third parties this product cannot work without. The active entries cover Stack Auth for authentication, Convex for the backend, a GitHub App with `CMUX_GITHUB_APP_ID` and `CMUX_GITHUB_APP_PRIVATE_KEY`, an `ANTHROPIC_API_KEY`, a `MORPH_API_KEY` for the sandbox, and a `CMUX_TASK_RUN_JWT_SECRET` for signing task runs. The commented-out lines are a roadmap. `OPENAI_API_KEY`, `GEMINI_API_KEY`, `VERTEX_PRIVATE_KEY` and `AWS_BEARER_TOKEN_BEDROCK` are all present but disabled, as are alternative sandbox providers such as E2B, Modal and a Vercel snapshot image. That is a design with one working path and several planned ones, which is worth knowing before you commit a migration. The host overrides section at the bottom documents the port layout of the dev setup, and it is the clearest map of how the pieces talk to each other: ```bash # CMUX_HOST_CLIENT=localhost:5173 # CMUX_HOST_SERVER=localhost:9779 # CMUX_HOST_VSCODE=localhost:39377 # CMUX_HOST_OPENCODE=127.0.0.1 # CMUX_HOST_AMP_PROXY= ``` A client on 5173, an orchestration server on 9779, a proxied VS Code on 39377 and a separate Opencode host, with an optional Amp proxy on top. Read that as: one process coordinates, several proxied IDE and agent runtimes sit behind it, and the browser talks only to the client. The AI keys section of the same file is equally explicit about what you must supply: ```bash ANTHROPIC_API_KEY= # OPENAI_API_KEY= # GEMINI_API_KEY= # VERTEX_PRIVATE_KEY= # AWS_BEARER_TOKEN_BEDROCK= # AWS_REGION= ``` Only the Anthropic key is uncommented, which matches the Claude Code first framing. ## The review features are the actual product Run the list of features again with this weighting and the picture changes. Parallel orchestration is table stakes in 2026. What is harder is everything the README puts after it. The live web preview puts your dev server inside the workspace, so an agent that just edited a React component can be checked against a running page without leaving the app. Source control access inside each workspace means each agent commits to its own branch instead of racing on yours. The pull request flow covers reviewing a diff, squashing, merging, or opening a PR, and it surfaces GitHub Actions results and CI status without a tab switch. Then there is workspace monitoring, which the README describes as seeing the agent's entire world at a glance: the VS Code editor, the Claude Code TUI, and a VNC browser preview in one view. This is the feature that answers a question agent orchestration usually ignores, which is whether the agent is stuck on a permission prompt or silently reading files for four minutes. And the heatmap diff viewer sits at the end of the list, described as automatically highlighting risky code changes with colour-coded annotations so review focuses on the lines that matter. There is a demo asset for it in the tree at `apps/www/assets/heatmap-demo-1.png`. Treat any such claim as unverified until you have seen it flag a real regression, but the idea is sound: a reviewer with twelve diffs needs triage help, and diff-level scoring is a cheaper first pass than model-level commentary. ## Install paths in the README have been deliberately commented out An odd detail worth reporting because it changes what a reader should expect. The README's Install section supports macOS with a download badge, marks Linux as beta and Windows as coming soon, and then contains the actual install commands wrapped in HTML comments. The commented block offers `bunx cmux@latest` and `npx cmux@latest`, plus a `uvx cmux@latest` variant in a second comment, and the Upgrade and Uninstall sections with `cmux upgrade` and `cmux uninstall` are commented out too. Why that happens is not unusual: a project whose primary distribution is a signed desktop build often keeps the package-manager commands alive but hidden while the app is the supported path. But the consequence for a reader is concrete. The npm package name and the binary name in that commented block are `cmux`, not `manaflow`, so a search for `npx manaflow` finds nothing. Anyone following the README literally needs to notice that the published package is still called cmux. The upgrade story is also thin. Self-update is not documented the way the AutoGLM-GUI project documents it across Windows, macOS and Linux AppImage, and the commented `cmux upgrade` command is the only mechanism named. On a tool that spawns long-running sandboxes, knowing how a half-finished update behaves matters more than usual. There is also a `run-notarytool.py` script and a `setup-notarytool.sh` in the root, which is macOS notarisation. That confirms the signed-desktop-build reading of the commented install block. ## 461 open issues and a stale release tag tell a clearer story The repository metadata is worth stating plainly, because it changes the reading of the star count. 1,113 stars, 61 forks and 461 open issues. That ratio of open issues to stars is high enough that it says something about the shape of the project: lots of people arrive, and a large share of them find something to file. Then the release history. Three releases are visible: v1.0.269 published 2026-02-19, v1.0.266 on 2026-02-12, and v1.0.263 on 2026-02-10. All three have empty release bodies, so there is no changelog to read, and all three sit in a five day window in February. Meanwhile the last push to `main` is 2026-09-19. That is roughly seven months of commits after the newest tag, which means either releases stopped being cut or they are being cut somewhere other than the public tag list. For a tool you install on your laptop and connect to your GitHub repository, that gap is the practical risk. There is no upgrade path to fall back on if a new build breaks your workflow, and no release note to tell you what changed under you. The root directory also carries `AGENTS.md`, `CLAUDE.md`, `PLAN.md`, `TODOS.md`, `REVIEW.md`, `CLEANUP.md`, `LAUNCH.md`, a `docs-ai/` folder, an `evals/` folder and a `prompt-wrapper.sh`. A repository with that many working documents left in the tree is a project in active development with its process left visible, which is either a good sign about how the author works or a sign about where the cleanup is in the queue. Both readings are consistent with 461 open issues. ## Conclusion Manaflow attacks a real problem: running four agents well means giving each one a workspace you can throw away, a way to see the diff it produced, and a way to run the thing before you believe it. It does all three, and the heatmap diff viewer is the piece most worth stealing even if you never install the app. The reservations are ordinary. It is macOS first with Linux in beta, it needs credentials for a cloud sandbox provider or a GitHub App to do anything beyond running an agent, and the repository still ships under the internal name `cmux` in package.json, pyproject.toml and every environment variable, which is a rename that has not finished. The numbers also deserve a second look: 461 open issues against 1,113 stars is a heavy queue, and the last tagged release v1.0.269 came on 2026-02-19 while the last push was 2026-09-19, so the repo is active without a release cadence. Judge it as a workbench for parallel runs rather than as managed infrastructure, and confirm one task end to end, sandbox to pull request, before adopting it as a habit. ## FAQ ### What is Manaflow and which coding agents does it support? Manaflow is an MIT licensed desktop application that spawns multiple coding agent CLIs in parallel, including Claude Code, Codex CLI, Cursor CLI, Gemini CLI, Amp and Opencode. Each run gets its own isolated VS Code workspace, hosted in the cloud or in a local Docker container, so several agents can work on one repository without fighting over the same checkout. ### How do I install Manaflow? The supported route is the macOS direct download linked from the README, with Linux in beta and Windows not yet available. The README also keeps package manager commands such as `npx cmux@latest` and `uvx cmux@latest` inside HTML comments, and note that the published package is still named `cmux` rather than `manaflow`. ### What API keys and services does Manaflow need to run? The `.env.example` requires Stack Auth credentials, a Convex URL, a GitHub App ID and private key, an `ANTHROPIC_API_KEY`, a `MORPH_API_KEY` for the sandbox provider and a `CMUX_TASK_RUN_JWT_SECRET`. Keys for OpenAI, Gemini, Vertex and Bedrock are present but commented out, so only the Anthropic path is enabled by default. ### How does Manaflow help with reviewing parallel agent work? Each workspace has source control access so agents commit to separate branches, a git diff view, an embedded dev server preview, CI status from GitHub Actions, and one-click pull request creation. There is also a heatmap diff viewer that colour-codes risky changes so a reviewer with many diffs can triage quickly. ### Is Manaflow the same project as cmux? It is the same codebase under a name that has not finished changing. The repository is Manaflow and the hosted service is manaflow.com, but `package.json` and `pyproject.toml` both declare the name `cmux`, every environment variable is prefixed `CMUX_`, and the Dockerfile builds with `ARG IDE_PROVIDER=cmux-code`. Search results for the CLI name are `cmux`. ## Sources - [Issues](https://github.com/manaflow-ai/manaflow/issues) - [License: MIT](https://github.com/manaflow-ai/manaflow/blob/main/LICENSE) - [manaflow-ai/manaflow on GitHub](https://github.com/manaflow-ai/manaflow) - [README](https://github.com/manaflow-ai/manaflow/blob/main/README.md) - [Releases](https://github.com/manaflow-ai/manaflow/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/manaflow-ai-manaflow