O IDE open source que não reimplementa nenhum agente: cada um roda pelo seu harness nativo
Toda ferramenta que promete rodar vários coding agents em paralelo tem que responder primeiro a mesma pergunta: o que faz com os agentes em si. Há duas respostas possíveis. Ou os reimplementa — escreve seu próprio cliente para cada provedor de modelos, seu próprio tool loop, seu próprio sistema de permissões — ou lança o binário do vendor e sai do caminho.
Proliferate escolheu a segunda, e diz isso em uma única linha do seu README:
“Each agent runs through its native harness, so auth, tools, models, permissions, and transcript behavior stay intact.”
(Cada agente roda através de seu harness nativo, então auth, tools, modelos, permissões e o comportamento do transcript ficam intactos.)
Essa frase é toda a decisão de produto. Tudo o mais — os worktrees em paralelo, a delegação entre agentes, os MCPs compartilhados — é o que se torna possível uma vez que você para de reescrever os agentes.
O projeto é AGPL-3.0, e a licença cobre mais que o cliente: “Proliferate is AGPL-3.0 — the whole stack: desktop client, web app, and cloud control plane.” A thread do Show HN (item 49390739) é pequena — 37 pontos, 15 comentários — mas deixou a descrição mais limpa do projeto, de um dos autores, respondendo para alguém que perguntava por que não usar Codex diretamente: “Codex only works with OpenAI models. Proliferate wraps around harnesses so it’s a strict superset of Codex.” (Codex só funciona com modelos de OpenAI; Proliferate envolve harnesses, então é um superconjunto estrito de Codex.)
Por que “harness nativo” não é um detalhe
Quando uma ferramenta reimplementa um agente, herda uma dívida de manutenção que não para de crescer. Anthropic lança um novo modo de permissões, OpenAI muda como Codex lida com aprovações, OpenCode adiciona um formato de plugins — e cada uma dessas coisas se torna um ticket no backlog de outra pessoa antes de você poder usá-la.
Rodar o harness do vendor inverte isso. O auth que você já configurou é o auth que funciona, porque é literalmente o mesmo processo lendo as mesmas credenciais. Sua seleção de modelo, suas regras de permissões, seu formato de transcript: intactos, porque ninguém os traduziu. E uma feature que saiu em Claude Code esta manhã está disponível em Proliferate esta manhã, não depois de um ciclo de release.
A lista, textual do README, é mais longa que a que costuma circular: “Native harnesses - Claude Code, Codex, OpenCode, Cursor, Grok, and more”. Cinco nomeados e uma porta aberta no final.
O trade-off é real e vale a pena nomeá-lo: o que um wrapper não consegue fazer é normalizar comportamento. Se Codex e Claude Code não concordam sobre o que significa “aprovar esta edição”, Proliferate não esconde isso de você — coloca os dois na mesma janela e deixa cada um se comportar como se comporta. Isso é uma feature se você já conhece os macetes de cada harness, e é fricção se esperava uma interface uniforme sobre tudo.
Um worktree por tarefa
O modelo de isolamento é a segunda decisão que sustenta o produto. Do README: “Worktree workspaces - an isolated branch and working directory for every task”, e em uma formulação mais completa, “Each task gets an isolated git worktree — branch, terminal, conversation, and review state kept together.”
Veja o que vem incluído nesse “kept together”: não são só os arquivos. A branch, o terminal, a conversa com o agente e o estado de review viajam como uma unidade. Essa é a diferença entre rodar quatro agentes e conseguir reconstruir, dois dias depois, o que o terceiro realmente estava fazendo e por que o diff ficou assim.
Em cima disso há três features que só fazem sentido uma vez que as tarefas estão isoladas:
- Delegação entre agentes. “Let your agents manage each other, like having Codex hand design work to Claude Code”, e “run agents side by side, or let them delegate scoped work to other agents”. A palavra que faz o trabalho aí é scoped: um agente delegado recebe um worktree, não seu repositório.
- Configurar uma vez, compartilhar em todos os lugares. “Set up MCPs and skills once, shared across every agent”. Se você já replicou uma configuração de MCP manualmente em três arquivos de config distintos, já sabe o que isso economiza.
- Agentes de review. “Plan & code review agents - reviewer agents check plans, diffs, risks, and branch readiness before you do”, mais review de git e diffs dentro da app para inspecionar e editar o que um agente mudou sem sair da ferramenta.
Também há workflows: “recurring and event-driven agent runs: nightly review passes, triage on alerts, dependency bumps”. Essa é a parte que transforma isso de um IDE em algo mais próximo a uma pequena superfície de ops, e é a parte que eu tocaria por último.
Levantá-lo localmente
Dois caminhos, e não estão no mesmo estado.
O binário. O release runtime-v0.4.25, publicado em 21 de agosto, traz assets para macOS em ARM64 e x86_64, Windows em ARM64 e x86_64, e Linux — então o enquadramento de “app para macOS” que circulou no lançamento ficou desatualizado. O README aponta para proliferate.com para os downloads e para proliferate.com/docs para a documentação.
Um aviso se você está em Windows, direto da thread do Show HN. O pedido de um comentarista foi seco — “Friendly ask: get the windows exes codesigned” — e a resposta do autor foi igualmente seca: “We’re on it! Apologies for the poor Windows experience in the meantime.” Executáveis não assinados em Windows não são um bloqueador em uma máquina pessoal e são em uma frota administrada. Ali convém esperar a assinatura.
Do código. Os requisitos do README são curtos:
- Rust stable
- Node.js 22+
- pnpm
e a execução são dois comandos:
make install
make dev-local
Se você quer o stack completo — com o control plane local incluído — a lista de requisitos cresce para Python 3.12+, uv e Docker para o banco de dados do control plane, e o fluxo passa a profiles com nome:
make server-install
make setup PROFILE=main
make build
make dev-list
make run PROFILE=main
Cada profile com nome mantém suas próprias portas, seu próprio banco Postgres, seu próprio runtime e sua própria identidade de app gerada, sob ~/.proliferate-local/dev/profiles/<name>/.Um profile por worktree é a recomendação do próprio projeto. Se você está no Windows, o guia de contribuição é explícito: o checkout vai no filesystem do WSL2 (~/proliferate), não sob /mnt/c.
Há um Discord em discord.gg/2RVNNzEZnj e um guia de contribuição no repositório.
Onde realmente termina a história do auto-hospedagem
Esta é a parte que merece precisão, porque a cobertura do lançamento a arredondou para o lado amável.
O control plane é sim auto-hospedável de verdade: “The full Proliferate control plane is self-hostable.” O guia de deployment descreve um stack de Docker Compose — Caddy, PostgreSQL, o API server, serviços opcionais — em um host Linux que você controla, com um instalador guiado, ou um template de AWS CloudFormation que provisiona uma instância EC2, um Elastic IP, uma VPC com uma subnet pública e um security group para as portas 80 e 443, dentro de sua própria conta. O gerenciamento de credenciais está pensado: os sandboxes recebem “short-lived virtual keys” em vez de credenciais completas, e a configuração do desktop guarda apenas apiBaseUrl, nunca credenciais do provedor.
E então duas frases da documentação do próprio projeto lhe colocam um limite.
A primeira, do guia de deployment auto-hospedado: “Cloud workspace runtimes are still provider-hosted.” Auto-hospedar o control plane não auto-hospeda os sandboxes na nuvem.
A segunda, do guia de AWS, é mais afiada. A descoberta do runtime bundle “currently expects x86 Linux binaries for provider sandboxes” enquanto o stack padrão roda em Graviton arm64, e o guia enuncia a consequência sem suavizá-la: “the default AWS cloud-workspace path is not proven. Do not switch archive architectures without resolving and testing that product boundary.” (O caminho padrão de cloud workspace em AWS não foi comprovado.)
Procurei a palavra “air-gapped” na documentação e não aparece. Pertence à cobertura, não ao projeto.
Nada disso danifica a história local, que é a que importa para a maioria dos leitores aqui: worktrees na sua própria máquina, cada agente autenticando-se pelo seu próprio harness com suas próprias credenciais, sem nada roteado pelo control plane de ninguém. Esse é um setup soberano, e é a parte sólida hoje. O que está em beta é a metade cloud — e o projeto diz isso por escrito, o que já é algo.
Que tipo de projeto é
Pré-1.0 e movendo-se rápido: versão 0.4.25 em 21 de agosto, com releases saindo diariamente. 2.698 commits, 43 forks, 71 pull requests abertos e 24 issues abertos no repositório.
A thread de Show HN é honesta sobre as arestas. Um usuário reportou que não conseguiu controlar de um Mac e um iPhone uma instância hospedada em um PC — “It was frustrating to set up and the docs confusing” — e recomendou um concorrente. Outro perguntou sobre mobile, e o autor foi direto: “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.”
Leia tudo isso junto e a forma fica clara. O caso de uso local, de uma única máquina e vários agentes em paralelo é o que funciona hoje, e a aposta arquitetônica por trás — não reimplementar os agentes — é a correta em uma categoria onde cada harness tira algo novo a cada semana. As peças distribuídas e de cloud auto-hospedado são um roadmap do qual você pode ler o código-fonte, que é mais do que oferece a maioria das ferramentas do ramo, mas são um roadmap.
Se você já tem Claude Code em um terminal, Codex em outro e está perdendo a conta de qual branch corresponde a qual conversa, isso vale uma tarde. Se você está avaliando como a plataforma que seu time vai padronizar, o número de versão está dizendo que espere, e o projeto também.
Como você está gerenciando hoje vários agentes em paralelo — worktrees à mão, tmux, ou alguma ferramenta que já resolveu o problema para você? Me conte o que quebra primeiro quando você passa de dois para quatro.