I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-checked-out repository. Instead, it requests Github permissions and clones the repo from Github. This is bad, because you need to run all the dependency installs, etc. for every workspace before being able to test anything. In other words it's like Codex or Cursor Background Agents, except worse, because it's on your machine. The reason I don't use Codex or Background Agents is because my project has way too many dependencies and would take way too long (and too complicated) to install everything required to have an isolated running instance, plus there would be DNS conflicts, external API conflicts, among other issues.
What I do want is simple git worktree management for an already-checked-out repo on my machine, no Github permissions or dependency re-installation (copying node_modules, etc.).
I'm the only user at the moment, and I really enjoy the workflow. I run about four claude-codes at once this way. It's a little underbaked but I think this is the way a lot of people are going to go. Seems like the 'par' tool in a sibling comment is a similar approach.
Containers do make things easier, especially since agents can see the log output of any service super easily. To do the same thing outside a container you need to send logs somewhere the agent can see.
Hey, you might be interested in my project Plandex[1] which uses a shadow git repo approach to keep changes separate until you approve them. It solves the same problem as worktrees.
I tried Crystal for the first time today and really enjoyed it. It’s a bit rough around the edges but it’s usable and notably it Does One Thing Really Well. All I wanted was a simple way to run a bunch of Claude codes in parallel and isolation and it does exactly that. No more, no less. No opinionation about how I organize my code, no custom config files I have to think about and manage, just simple work isolation workflow with a GUI.
I tried out git worktrees recently and while they do what's on the tin, I really didn't like them as much as I thought I would. I actually like the way cursor does it despite the fact that it is a VM - I wish I could have their same UI/UX but with local worktrees.
The git worktrees feature has first garnered public attention since anthropic mentioned it in its claude code good practices. Until then it was just one of these obscure git features most professionals have never heard of.
Now all these agents and claude code wrappers are trying to make use of git worktrees - but in all honesty - it's overcomplicating most workflows more than being of a real use for agentic coding. The bottleneck was - for most workflows - never the ai not being able to write 10 different poc of my feature simultaneously - but the human factor - needing to carefully review what ai produced and still steering ai in the right direction. git worktrees doesn't help solve any of these problems. it just adds an unnecessary layer on top.
Babysitting one process, but giving it all of my attention[1] can lead to rapid progress.
Pushing forward multiple efforts simultaneously can lead to rapid progress if code is largely unrelated and you keep a sharp eye on branching and commits.
However, it’s remarkably easy to make a mistake and be enamored by how well the AI can use git to fix your mistake.
But the cost ends up being adherence to it, specification or architecture, or being distracted into scope creep.
The new scope might be useful for factoring, but that is also the kind of thing that interfere with your Main processor trying to handle.
And it’s remarkably easy to get lost in the state when you have to manage validation well.
The more mature the project and more intense the expectation of scm hygiene, the more punitive small mistakes can become.
It is not really a problem in my process prior to Claude code, which was almost entirely turned based chat.
I still have configured fairly complex and detailed session workflows to preserve state amidst the regular threat of auto compact.
Even I even have documentation, describing a plan to migrate into git worktrees myself, but haven’t been able to justify the move, as I continue to learn to be productive with a single main session focus.
[1] I don’t know if there is such a thing as constant focus on a complex genetic programming effort because of the delays involved. You can stare at the funny verbs anthropic picks while the tokens go brrrr for only so long.
Yes, the bottleneck is going to still be human review. But with only a single Claude Code (or Cursor), I spent a lot of time (a couple minutes at a time) waiting for the agent to run through its loop completing what I asked it to do. In this time I found I was naturally switching context, but not always productively (checking slack, email, whatever). I called it "agent lag" time.
Now with these worktrees tools, I can easily bounce between tasks I have the agents working on during these natural lulls. Overall I'm able to get more done and spend my time more efficiently.
Also, Cursor has had the option to run multiple agents for a while (in tabs), but I always found it cumbersome because all the agents are operating on the same git checkout, so you have to take special care for them not to conflict with each other. Worktrees completely solve that problem.
Yes I had a similar experience. the thing that tripped me up with git worktrees, which is maybe obvious in retrospect, is that they don’t include things that are not tracked by git - e.g. .env.development.local
So starting a new worktree requires additional setup and isn’t as simple as just checking out a new branch
Sorry about that! We’re working on making this more intuitive.
Internally our workflow looks like this:
- we have a script that sets up a repo — copies env variables, runs pnpm i, inits a db, etc
- we have a field in the repo settings called “setup script.” every time you make a new workspace, that script runs
Hopefully will be much improved over the next week or two!
I'm working on a little wrapper that solves this problem. I have similar needs with .env files, and in my case running 'uv sync' to install dependencies. I linked it elsewhere in this thread so I won't repeat the URL (autowt). It's definitely possible to make this workflow effective with some scripting.
But that is also the selling point of worktrees - I have them for multiple features I am working on, I just spin up services that I need for each feature separately, like databases, etc. How else are you going to isolate migrations, configuration changes, etc.
check out https://github.com/dagger/container-use! it uses worktrees under the hood, but hides them from the user and agent. it basically gives you containers tracked by git branches and plugs into any MCP-compatible agent. you're then free to make your own worktrees from those branches, but you can also just use them in your normal checkout.
Hi, creator here. If you want to copy node_modules instead of reinstalling, you can click on the repo and add a setup script that does the copy. Sorry it’s a bit obscure—we’re working on making this easier!
Would love to discuss more what kind of testing setup you’re looking for, want to shoot me an email at jackson@melty.sh?
Also the working on PRs workflow seems broken - the local branch doesn't have the changes that are on the PR so I can't pick it up and continue working on it.
"This is bad, because you need to run all the dependency installs", you must be using Python or one of the other locally cached dependency language tookings. Is never understood why people wanto clone everything every time. Maven and its sibling use ~/.m2 so everything gets cached once. I ceinge every time I have to re-download the universe when I inevitably have to delete my venv and redo anything, what a waste of time and bandwidth and space.
I just tried Claude Squad this morning , the instructions to use and interface was very clunky . There also was no uninstall instructions or scripts , so I had to write one and uninstall it. Lame
How do you suggest simultaneous independent branches be worked on concurrently from a single repository copy, or is it that you would simply prefer the local work tree method of duplication? And, for example, how do you suggest the same node_modules be used if part of the task requires changing, removing, or updating dependencies? Additionally, how much time do you expect a developer to spend implementing this new system your suggesting across all platforms for the benefit of it taking you a bit less time, especially when pulling dependencies from a local caches as I’m sure you’re doing? Or are you making a suggestion that you plan to contribute?
I’m sure the authors would appreciate well-thought alternative suggestions and assistance.
What I do want is simple git worktree management for an already-checked-out repo on my machine, no Github permissions or dependency re-installation (copying node_modules, etc.).