El IDE open source que no reimplementa ningún agente: cada uno corre por su harness nativo
Toda herramienta que promete correr varios coding agents en paralelo tiene que responder primero la misma pregunta: qué hace con los agentes en sí. Hay dos respuestas posibles. O los reimplementas — escribes tu propio cliente para cada proveedor de modelos, tu propio tool loop, tu propio sistema de permisos — o lanzas el binario del vendor y te haces a un lado.
Proliferate eligió la segunda, y lo dice en una sola línea de su README:
“Each agent runs through its native harness, so auth, tools, models, permissions, and transcript behavior stay intact.”
(Cada agente corre a través de su harness nativo, así que auth, tools, modelos, permisos y el comportamiento del transcript quedan intactos.)
Esa frase es toda la decisión de producto. Todo lo demás — los worktrees en paralelo, la delegación entre agentes, los MCPs compartidos — es lo que se vuelve posible una vez que dejas de reescribir los agentes.
El proyecto es AGPL-3.0, y la licencia cubre más que el cliente: “Proliferate is AGPL-3.0 — the whole stack: desktop client, web app, and cloud control plane.” El thread de Show HN (item 49390739) es chico — 37 puntos, 15 comentarios — pero dejó la descripción más limpia del proyecto, de uno de los autores, respondiéndole a alguien que preguntaba por qué no usar Codex directamente: “Codex only works with OpenAI models. Proliferate wraps around harnesses so it’s a strict superset of Codex.” (Codex solo funciona con modelos de OpenAI; Proliferate envuelve harnesses, así que es un superconjunto estricto de Codex.)
Por qué “harness nativo” no es un detalle
Cuando una herramienta reimplementa un agente, hereda una deuda de mantenimiento que no deja de crecer. Anthropic saca un nuevo modo de permisos, OpenAI cambia cómo Codex maneja las aprobaciones, OpenCode agrega un formato de plugins — y cada una de esas cosas se convierte en un ticket en el backlog de otra persona antes de que puedas usarla.
Correr el harness del vendor invierte eso. El auth que ya configuraste es el auth que funciona, porque es literalmente el mismo proceso leyendo las mismas credenciales. Tu selección de modelo, tus reglas de permisos, tu formato de transcript: intactos, porque nadie los tradujo. Y una feature que salió en Claude Code esta mañana está disponible en Proliferate esta mañana, no después de un ciclo de release.
La lista, textual del README, es más larga que la que suele circular: “Native harnesses - Claude Code, Codex, OpenCode, Cursor, Grok, and more”. Cinco nombrados y una puerta abierta al final.
El trade-off es real y vale la pena nombrarlo: lo que un wrapper no puede hacer es normalizar comportamiento. Si Codex y Claude Code no se ponen de acuerdo sobre qué significa “aprobar esta edición”, Proliferate no te lo esconde — pone a los dos en la misma ventana y deja que cada uno se comporte como se comporta. Eso es una feature si ya conoces las mañas de cada harness, y es fricción si esperabas una interfaz uniforme sobre todo.
Un worktree por tarea
El modelo de aislamiento es la segunda decisión que sostiene el producto. Del README: “Worktree workspaces - an isolated branch and working directory for every task”, y en una formulación más completa, “Each task gets an isolated git worktree — branch, terminal, conversation, and review state kept together.”
Fíjate qué viene incluido en ese “kept together”: no son solo los archivos. La branch, la terminal, la conversación con el agente y el estado de review viajan como una unidad. Esa es la diferencia entre correr cuatro agentes y poder reconstruir, dos días después, qué estaba haciendo realmente el tercero y por qué el diff quedó así.
Encima de eso hay tres features que solo tienen sentido una vez que las tareas están aisladas:
- Delegación entre agentes. “Let your agents manage each other, like having Codex hand design work to Claude Code”, y “run agents side by side, or let them delegate scoped work to other agents”. La palabra que hace el trabajo ahí es scoped: un agente delegado recibe un worktree, no tu repositorio.
- Configurar una vez, compartir en todos lados. “Set up MCPs and skills once, shared across every agent”. Si alguna vez replicaste una configuración de MCP a mano en tres archivos de config distintos, ya sabes qué te ahorra esto.
- Agentes de review. “Plan & code review agents - reviewer agents check plans, diffs, risks, and branch readiness before you do”, más review de git y diffs dentro de la app para inspeccionar y editar lo que cambió un agente sin salir de la herramienta.
También hay workflows: “recurring and event-driven agent runs: nightly review passes, triage on alerts, dependency bumps”. Esa es la parte que convierte esto de un IDE en algo más cercano a una pequeña superficie de ops, y es la parte que yo tocaría al final.
Levantarlo en local
Dos caminos, y no están en el mismo estado.
El binario. El release runtime-v0.4.25, publicado el 21 de agosto, trae assets para macOS en ARM64 y x86_64, Windows en ARM64 y x86_64, y Linux — así que el encuadre de “app para macOS” que circuló en el lanzamiento quedó desactualizado. El README apunta a proliferate.com para las descargas y a proliferate.com/docs para la documentación.
Una advertencia si estás en Windows, directo del thread de Show HN. El pedido de un comentarista fue seco — “Friendly ask: get the windows exes codesigned” — y la respuesta del autor fue igual de seca: “We’re on it! Apologies for the poor Windows experience in the meantime.” Ejecutables sin firmar en Windows no son un bloqueante en una máquina personal y sí lo son en una flota administrada. Ahí conviene esperar la firma.
Desde el código. Los requisitos del README son cortos:
- Rust stable
- Node.js 22+
- pnpm
y la ejecución son dos comandos:
make install
make dev-local
Si quieres el stack completo — con el control plane local incluido — la lista de requisitos crece a Python 3.12+, uv y Docker para la base de datos del control plane, y el flujo pasa a profiles con nombre:
make server-install
make setup PROFILE=main
make build
make dev-list
make run PROFILE=main
Cada profile con nombre mantiene sus propios puertos, su propia base Postgres, su propio runtime y su propia identidad de app generada, bajo ~/.proliferate-local/dev/profiles/<name>/. Un profile por worktree es la recomendación del propio proyecto. Si estás en Windows, la guía de contribución es explícita: el checkout va en el filesystem de WSL2 (~/proliferate), no bajo /mnt/c.
Hay un Discord en discord.gg/2RVNNzEZnj y una guía de contribución en el repo.
Dónde termina realmente la historia del self-hosting
Esta es la parte que merece precisión, porque la cobertura del lanzamiento la redondeó hacia el lado amable.
El control plane sí es auto-hospedable de verdad: “The full Proliferate control plane is self-hostable.” La guía de deployment describe un stack de Docker Compose — Caddy, PostgreSQL, el API server, servicios opcionales — sobre un host Linux que controlas, con un instalador guiado, o un template de AWS CloudFormation que aprovisiona una instancia EC2, una Elastic IP, una VPC con una subnet pública y un security group para los puertos 80 y 443, dentro de tu propia cuenta. El manejo de credenciales está pensado: los sandboxes reciben “short-lived virtual keys” en vez de credenciales completas, y la configuración del desktop guarda solo el apiBaseUrl, nunca credenciales del proveedor.
Y entonces dos frases de la documentación del propio proyecto le ponen un límite.
La primera, de la guía de deployment self-hosted: “Cloud workspace runtimes are still provider-hosted.” Auto-hospedar el control plane no auto-hospeda los sandboxes en la nube.
La segunda, de la guía de AWS, es más filosa. El descubrimiento del runtime bundle “currently expects x86 Linux binaries for provider sandboxes” mientras el stack por defecto corre sobre Graviton arm64, y la guía enuncia la consecuencia sin suavizarla: “the default AWS cloud-workspace path is not proven. Do not switch archive architectures without resolving and testing that product boundary.” (El camino por defecto de cloud workspace en AWS no está probado.)
Busqué la palabra “air-gapped” en la documentación y no aparece. Pertenece a la cobertura, no al proyecto.
Nada de eso daña la historia local, que es la que importa para la mayoría de los lectores acá: worktrees en tu propia máquina, cada agente autenticándose por su propio harness con sus propias credenciales, sin nada ruteado por el control plane de nadie. Eso es un setup soberano, y es la parte sólida hoy. Lo que está en beta es la mitad cloud — y el proyecto lo dice por escrito, que ya es algo.
Qué clase de proyecto es
Pre-1.0 y moviéndose rápido: versión 0.4.25 el 21 de agosto, con releases saliendo a diario. 2.698 commits, 43 forks, 71 pull requests abiertos y 24 issues abiertos en el repositorio.
El thread de Show HN es honesto sobre las aristas. Un usuario reportó que no logró controlar desde una Mac y un iPhone una instancia hospedada en una PC — “It was frustrating to set up and the docs confusing” — y recomendó un competidor. Otro preguntó por mobile, y el autor fue directo: “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.”
Lee todo eso junto y la forma queda clara. El caso de uso local, de una sola máquina y varios agentes en paralelo es lo que funciona hoy, y la apuesta arquitectónica detrás — no reimplementar los agentes — es la correcta en una categoría donde cada harness saca algo nuevo cada semana. Las piezas distribuidas y de cloud self-hosted son un roadmap del que puedes leer el código fuente, que es más de lo que ofrece la mayoría de las herramientas del rubro, pero son un roadmap.
Si ya tienes Claude Code en una terminal, Codex en otra y estás perdiendo la cuenta de qué branch corresponde a qué conversación, esto vale una tarde. Si lo estás evaluando como la plataforma que tu equipo va a estandarizar, el número de versión te está diciendo que esperes, y el proyecto también.
¿Cómo estás manejando hoy varios agentes en paralelo — worktrees a mano, tmux, o alguna herramienta que ya te resolvió el problema? Cuéntame qué se te rompe primero cuando pasas de dos a cuatro.