This product was not featured by Product Hunt yet. It will not be visible on their landing page and won't be ranked (cannot win product of the day regardless of upvotes).
Product upvotes vs the next 3
Waiting for data. Loading
Product comments vs the next 3
Waiting for data. Loading
Product upvote speed vs the next 3
Waiting for data. Loading
Product upvotes and comments
Waiting for data. Loading
Product vs the next 3
Loading
Rhizome MCP
A shared execution layer for coding agents
Unlike chat memory or human-first task trackers, Rhizome MCP gives coding agents shared execution state: atomic claims, renewable leases, restartable checkpoints, conflict detection, and handoffs. v1.1 adds multi-project routing through one local server and stateless MCP 2026-07-28 support while retaining legacy compatibility. It is local-first, open source, and runs as a single SQLite-backed binary.
I built Rhizome MCP after trying to coordinate multiple coding agents with Markdown task files on another project. The files could describe the work, but they could not reliably answer who was working on a task, recover when an agent disappeared, or prevent two sessions from choosing the same thing. Useful findings also vanished when a session ran out of context.
That convinced me coding agents need a shared execution layer, not another chat history.
Rhizome gives agents a shared backlog with atomic task claims, renewable leases, restartable checkpoints, conflict detection, and review handoffs. If an agent disappears, its lease expires and the task becomes available again. The next session can continue from a compact checkpoint instead of repeating the investigation.
Version 1.0 proved this coordination model, but using it after release exposed a product flaw. Rhizome understood one repository at a time, while one MCP installation is naturally used across many workspaces. Users had to maintain workspace-specific registrations or run separate server instances just to ensure an agent reached the right project. I had built a coordinator for agents, then left the human coordinating the server.
This release fixes that with shared project routing. One local Rhizome server can now serve multiple initialized projects while keeping their work isolated. An agent explicitly opens its repository and carries that project reference through the workflow, with no hidden global current project for another session to change.
Rhizome now also supports MCP version 2026-07-28 and its stateless request flow. Work ownership, recovery, and agent attribution no longer depend on one connection staying alive. Legacy 2025-11-25 clients remain supported, so adopting the new protocol does not create a compatibility cliff.
Rhizome is local-first, open source, and distributed as a single SQLite-backed Go binary. You can try it with npx rhizome-mcp serve, install it directly, or use the VS Code extension that bundles and registers the server.
I would especially value feedback from people running Copilot, Claude Code, Codex, or other MCP clients across multiple repositories. Where does agent coordination still break down? Do clients follow the claim, checkpoint, and finish workflow consistently? Does one shared local server make setup meaningfully easier?
Thanks for taking a look!
About Rhizome MCP on Product Hunt
“A shared execution layer for coding agents”
Rhizome MCP was submitted on Product Hunt and earned 2 upvotes and 1 comments, placing #150 on the daily leaderboard. Unlike chat memory or human-first task trackers, Rhizome MCP gives coding agents shared execution state: atomic claims, renewable leases, restartable checkpoints, conflict detection, and handoffs. v1.1 adds multi-project routing through one local server and stateless MCP 2026-07-28 support while retaining legacy compatibility. It is local-first, open source, and runs as a single SQLite-backed binary.
On the analytics side, Rhizome MCP competes within Open Source, Developer Tools, Artificial Intelligence and GitHub — topics that collectively have 1.1M followers on Product Hunt. The dashboard above tracks how Rhizome MCP performed against the three products that launched closest to it on the same day.
Who hunted Rhizome MCP?
Rhizome MCP was hunted by Egor Komarov. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
For a complete overview of Rhizome MCP including community comment highlights and product details, visit the product overview.
Egor Komarov
Hi Product Hunt!
I built Rhizome MCP after trying to coordinate multiple coding agents with Markdown task files on another project. The files could describe the work, but they could not reliably answer who was working on a task, recover when an agent disappeared, or prevent two sessions from choosing the same thing. Useful findings also vanished when a session ran out of context.
That convinced me coding agents need a shared execution layer, not another chat history.
Rhizome gives agents a shared backlog with atomic task claims, renewable leases, restartable checkpoints, conflict detection, and review handoffs. If an agent disappears, its lease expires and the task becomes available again. The next session can continue from a compact checkpoint instead of repeating the investigation.
Version 1.0 proved this coordination model, but using it after release exposed a product flaw. Rhizome understood one repository at a time, while one MCP installation is naturally used across many workspaces. Users had to maintain workspace-specific registrations or run separate server instances just to ensure an agent reached the right project. I had built a coordinator for agents, then left the human coordinating the server.
This release fixes that with shared project routing. One local Rhizome server can now serve multiple initialized projects while keeping their work isolated. An agent explicitly opens its repository and carries that project reference through the workflow, with no hidden global current project for another session to change.
Rhizome now also supports MCP version 2026-07-28 and its stateless request flow. Work ownership, recovery, and agent attribution no longer depend on one connection staying alive. Legacy 2025-11-25 clients remain supported, so adopting the new protocol does not create a compatibility cliff.
Rhizome is local-first, open source, and distributed as a single SQLite-backed Go binary. You can try it with npx rhizome-mcp serve, install it directly, or use the VS Code extension that bundles and registers the server.
I would especially value feedback from people running Copilot, Claude Code, Codex, or other MCP clients across multiple repositories. Where does agent coordination still break down? Do clients follow the claim, checkpoint, and finish workflow consistently? Does one shared local server make setup meaningfully easier?
Thanks for taking a look!