The Open Source IDE That Doesn’t Reimplement Any Agent: Each One Runs Through Its Native Harness
Every tool that promises to run multiple coding agents in parallel has to answer the same question first: what do you do with the agents themselves. There are two possible answers. Either you reimplement them — you write your own client for each model provider, your own tool loop, your own permissions system — or you launch the vendor’s binary and get out of the way.
Proliferate chose the second, and it says so in a single line of its README:
“Each agent runs through its native harness, so auth, tools, models, permissions, and transcript behavior stay intact.”
That sentence is the entire product decision. Everything else — the parallel worktrees, the delegation between agents, the shared MCPs — is what becomes possible once you stop rewriting the agents.
The project is AGPL-3.0, and the license covers more than the client: “Proliferate is AGPL-3.0 — the whole stack: desktop client, web app, and cloud control plane.” The Show HN thread (item 49390739) is small — 37 points, 15 comments — but it left the cleanest description of the project, from one of the authors, replying to someone asking why not use Codex directly: “Codex only works with OpenAI models. Proliferate wraps around harnesses so it’s a strict superset of Codex.”
Why “Native Harness” Isn’t a Detail
When a tool reimplements an agent, it inherits a maintenance debt that never stops growing. Anthropic releases a new permissions mode, OpenAI changes how Codex handles approvals, OpenCode adds a plugin format — and each of those becomes a ticket in someone else’s backlog before you can use it.
Running the vendor’s harness inverts that. The auth you already configured is the auth that works, because it’s literally the same process reading the same credentials. Your model selection, your permission rules, your transcript format: intact, because nobody translated them. And a feature that shipped in Claude Code this morning is available in Proliferate this morning, not after a release cycle.
The list, verbatim from the README, is longer than what usually circulates: “Native harnesses - Claude Code, Codex, OpenCode, Cursor, Grok, and more”. Five named and an open door at the end.
The trade-off is real and worth naming: what a wrapper can’t do is normalize behavior. If Codex and Claude Code don’t agree on what “approve this edit” means, Proliferate doesn’t hide it from you — it puts both in the same window and lets each one behave as it behaves. That’s a feature if you already know the quirks of each harness, and it’s friction if you expected a uniform interface across everything.
One Worktree Per Task
The isolation model is the second decision that sustains the product. From the README: “Worktree workspaces - an isolated branch and working directory for every task”, and in a more complete formulation, “Each task gets an isolated git worktree — branch, terminal, conversation, and review state kept together.”
Notice what comes included in that “kept together”: it’s not just the files. The branch, the terminal, the conversation with the agent, and the review state travel as a unit. That’s the difference between running four agents and being able to reconstruct, two days later, what the third one was actually doing and why the diff ended up that way.
On top of that are three features that only make sense once tasks are isolated:
- Delegation between agents. “Let your agents manage each other, like having Codex hand design work to Claude Code”, and “run agents side by side, or let them delegate scoped work to other agents”. The word that does the work there is scoped: a delegated agent receives a worktree, not your repository.
- Configure once, share everywhere. “Set up MCPs and skills once, shared across every agent”. If you’ve ever replicated an MCP configuration by hand across three different config files, you already know what this saves you.
- Review agents. “Plan & code review agents - reviewer agents check plans, diffs, risks, and branch readiness before you do”, plus git review and diffs inside the app to inspect and edit what an agent changed without leaving the tool.
There’s also workflows: “recurring and event-driven agent runs: nightly review passes, triage on alerts, dependency bumps”. That’s the part that turns this from an IDE into something closer to a small ops surface, and it’s the part I’d touch last.
Running It Locally
Two paths, and they’re not in the same state.
The binary. The runtime-v0.4.25 release, published on August 21st, brings assets for macOS on ARM64 and x86_64, Windows on ARM64 and x86_64, and Linux — so the “macOS app” framing that circulated at launch is outdated. The README points to proliferate.com for downloads and proliferate.com/docs for documentation.
A heads-up if you’re on Windows, straight from the Show HN thread. One commenter’s request was terse — “Friendly ask: get the windows exes codesigned” — and the author’s response was equally terse: “We’re on it! Apologies for the poor Windows experience in the meantime.” Unsigned executables on Windows aren’t a blocker on a personal machine but they are on a managed fleet. Best to wait for signing there.
From source. The README’s requirements are short:
- Rust stable
- Node.js 22+
- pnpm
and the execution is two commands:
make install
make dev-local
If you want the full stack — with the local control plane included — the requirements list grows to Python 3.12+, uv, and Docker for the control plane’s database, and the flow moves to named profiles:
make server-install
make setup PROFILE=main
make build
make dev-list
make run PROFILE=main
Each named profile maintains its own ports, its own Postgres database, its own runtime, and its own generated app identity, under ~/.proliferate-local/dev/profiles/<name>/.One profile per worktree is the recommendation from the project itself. If you’re on Windows, the contribution guide is explicit: the checkout goes in the WSL2 filesystem (~/proliferate), not under /mnt/c.
There’s a Discord at discord.gg/2RVNNzEZnj and a contribution guide in the repo.
Where the self-hosting story really ends
This is the part that deserves precision, because the launch coverage rounded it toward the friendly side.
The control plane is genuinely self-hostable: “The full Proliferate control plane is self-hostable.” The deployment guide describes a Docker Compose stack — Caddy, PostgreSQL, the API server, optional services — on a Linux host you control, with a guided installer, or an AWS CloudFormation template that provisions an EC2 instance, an Elastic IP, a VPC with a public subnet and a security group for ports 80 and 443, within your own account. Credential handling is thoughtful: sandboxes receive “short-lived virtual keys” instead of full credentials, and the desktop configuration stores only the apiBaseUrl, never provider credentials.
And then two sentences from the project’s own documentation put a limit on it.
The first, from the self-hosted deployment guide: “Cloud workspace runtimes are still provider-hosted.” Self-hosting the control plane doesn’t self-host the cloud sandboxes.
The second, from the AWS guide, is sharper. Runtime bundle discovery “currently expects x86 Linux binaries for provider sandboxes” while the default stack runs on Graviton arm64, and the guide states the consequence without softening it: “the default AWS cloud-workspace path is not proven. Do not switch archive architectures without resolving and testing that product boundary.” (The default cloud workspace path on AWS is not proven.)
I searched for the word “air-gapped” in the documentation and it doesn’t appear. It belongs to the coverage, not the project.
None of that damages the local story, which is the one that matters for most readers here: worktrees on your own machine, each agent authenticating through its own harness with its own credentials, with nothing routed through anyone’s control plane. That’s a sovereign setup, and it’s the solid part today. What’s in beta is the cloud half — and the project says so in writing, which is something.
What kind of project this is
Pre-1.0 and moving fast: version 0.4.25 on August 21st, with releases coming out daily. 2,698 commits, 43 forks, 71 open pull requests and 24 open issues in the repository.
The Show HN thread is honest about the rough edges. One user reported they couldn’t control from a Mac and iPhone an instance hosted on a PC — “It was frustrating to set up and the docs confusing” — and recommended a competitor. Another asked about mobile, and the author was direct: “We don’t currently support mobile access as a first class feature—we have a beta version available but don’t want to release to GA yet.”
Read all that together and the shape becomes clear. The local use case, single machine and multiple agents in parallel, is what works today, and the architectural bet behind it — not reimplementing the agents — is the right one in a category where each harness releases something new every week. The distributed and cloud self-hosted pieces are a roadmap you can read the source code for, which is more than most tools in this space offer, but they are a roadmap.
If you already have Claude Code in one terminal, Codex in another and you’re losing track of which branch goes with which conversation, this is worth an afternoon. If you’re evaluating it as the platform your team will standardize on, the version number is telling you to wait, and so is the project.
How are you handling multiple agents in parallel today — worktrees by hand, tmux, or some tool that already solved the problem for you? Tell me what breaks first when you go from two to four.