worktrunk Quietly Became a Platform Because Everyone Runs Five Agents Now
max-sixty/worktrunk is a CLI for managing git worktrees, built for parallel AI agent workflows. It's at 7,198 stars, it trended again on GitHub with 137 stars in a day, and it shipped v0.77.0 on September 8 with commits landing as recently as yesterday. Repo at https://github.com/max-sixty/worktrunk . That's a healthy tool. The interesting part is what's grown around it.
Search GitHub for worktrunk and you get more than a dozen third-party projects. herdr-worktrunk at 144 stars wiring it into a fleet manager, pi-worktrunk that repaints branch markers to show agent status, worktrunk-sync for rebasing stacked worktree branches in dependency order, opencode-worktrunk, worktrunk-codex, two separate Neovim plugins written by two people who apparently didn't know about each other, two zsh plugins, a Node wrapper. Nobody builds an integration ecosystem for a git convenience wrapper. They build one for a thing that sits in the middle of a daily workflow.
The reason is mundane and that's what makes it real. Running several coding agents at once on one repo does not work if they share a working tree, because they stomp each other's uncommitted changes. Git already solved this in 2015 with worktrees, and the command surface is genuinely awkward enough that nobody used it casually. worktrunk makes create-a-tree-run-an-agent-throw-it-away a single fast command, and the moment that's fast, running four agents becomes the default instead of a stunt.
Look at the plugin list and the shape of the emerging stack is right there: fleet orchestration on top, worktrees as the isolation primitive underneath, editor and shell integrations gluing the two together. The status-marker plugins in particular are the tell, because they exist to answer "which of my five branches has an agent actively working on it," which is a question that did not exist as a daily problem eighteen months ago.
This pairs directly with [Herdr going multi-machine](https://clauday.com/article/f99c62c2-f0ff-486e-a796-8cd16b4d2e07). Herdr's answer to the fleet problem was more machines. worktrunk's is more isolation on the one you have, and the fact that somebody wrote a bridge between them tells you people are doing both. If you're still running one agent at a time in your main checkout, this is the cheapest possible upgrade: it's a CLI, it changes nothing about how you work except making the expensive part free.
← Back to all articles
Search GitHub for worktrunk and you get more than a dozen third-party projects. herdr-worktrunk at 144 stars wiring it into a fleet manager, pi-worktrunk that repaints branch markers to show agent status, worktrunk-sync for rebasing stacked worktree branches in dependency order, opencode-worktrunk, worktrunk-codex, two separate Neovim plugins written by two people who apparently didn't know about each other, two zsh plugins, a Node wrapper. Nobody builds an integration ecosystem for a git convenience wrapper. They build one for a thing that sits in the middle of a daily workflow.
The reason is mundane and that's what makes it real. Running several coding agents at once on one repo does not work if they share a working tree, because they stomp each other's uncommitted changes. Git already solved this in 2015 with worktrees, and the command surface is genuinely awkward enough that nobody used it casually. worktrunk makes create-a-tree-run-an-agent-throw-it-away a single fast command, and the moment that's fast, running four agents becomes the default instead of a stunt.
Look at the plugin list and the shape of the emerging stack is right there: fleet orchestration on top, worktrees as the isolation primitive underneath, editor and shell integrations gluing the two together. The status-marker plugins in particular are the tell, because they exist to answer "which of my five branches has an agent actively working on it," which is a question that did not exist as a daily problem eighteen months ago.
This pairs directly with [Herdr going multi-machine](https://clauday.com/article/f99c62c2-f0ff-486e-a796-8cd16b4d2e07). Herdr's answer to the fleet problem was more machines. worktrunk's is more isolation on the one you have, and the fact that somebody wrote a bridge between them tells you people are doing both. If you're still running one agent at a time in your main checkout, this is the cheapest possible upgrade: it's a CLI, it changes nothing about how you work except making the expensive part free.
Comments