It would be interesting to have a general fix for this in git. Something that more carefully splits the metadata from the working copy, a bit like we used to routinely do with "shadow build trees" with autoconf+make etc.
The parallel trees could have different ownership and access privileges, so that the editable working copy does not require the same filesystem access rights as the metadata tree. The git CLI actions would be performed with the more privileged filesystem role, and it would also have to be audited to make sure it treats all the working copy content as untrusted payload.
For me the most pragmatic way to solve this is in the agent harness layer simply prohibiting commands like git force and others in the settings configuration of your harness of choice with pre tool hooks, its quite easy to setup, obvious ones are prohibiting pushes to main, among others.
Unless someone is building their harness from scratch like you this is a 30sec configuration and you could just save your list of blocked commands with wildcards in a file, and copy paste from one harness to the other.
Agreed. I had to solve this at the harness layer myself. It just makes more sense to me this way. We basically created hooks around these operations and you can configure what happens at these calls.
Disclosure: I'm building AQ (aq.dev) a multiplayer coding harness.
Worktrees are the obvious pick, and I get why. One command, cheap, and if you're the only one driving, then sharing .git is the point rather than a compromise. I started there too.
An agent in a worktree can reach your hooks, your config, another worktree's stash. Probably not a common problem. But when it does happen you're not debugging your code, you're debugging git, and it's not obvious where to even start looking.
The one that actually bothers me is prompt injection. The agent reads an issue, or a dependency's README, or a web page, and what it's told to do is drop a file in the .git it can already write to. Next time you commit, that runs on your machine as you.
Separate thing - worktrees just get annoying to manage. Can't check out the same branch twice, so you're making up branch names to keep git happy. Every one is another directory to keep track of. Then something goes stale and you're back in git worktree prune.
So has any of it got to you? Or do you hit the annoying parts, shrug, and carry on?
I haven’t hit these issues when using worktrees. But what’s a pain is having to compile from scratch every time, and not carrying over gitignored files.
I set up a custom hook in Claude which runs my own worktree creation/cleanup script, which takes care of copying my node_modules into the worktree, my .env (plus doing some edits to the .env to isolate it so it can run in parallel), and stuff like that. Each worktree gets its own docker compose project name so they can run docker stacks in parallel. Works pretty seamlessly.
Please stop writing straw man arguments to sell your product. Worktrees do work as intended for most people. And they work better than your broken homepage.
Agreed, that's my conclusion too. The point isn't that worktrees should be a boundary, it's that a lot of tooling hands agents a worktree and calls it isolation. And the hook thing is why you can't just wrap a worktree in a container to fix it: the worktree's own state lives in the parent's .git, so you'd have to mount that, and then a writable .git/hooks runs on the host. So containers, yes, but around a clone rather than a worktree.
Do people not know how to write blogs without AI anymore? I enjoy hearing a human's unique voice and miss hearing it when it's abscent.
You can literally tell from the box styling that it's AI now. Awful.
It would be interesting to have a general fix for this in git. Something that more carefully splits the metadata from the working copy, a bit like we used to routinely do with "shadow build trees" with autoconf+make etc.
The parallel trees could have different ownership and access privileges, so that the editable working copy does not require the same filesystem access rights as the metadata tree. The git CLI actions would be performed with the more privileged filesystem role, and it would also have to be audited to make sure it treats all the working copy content as untrusted payload.
I don't think people use it for isolation, but for what the feature enables in the first place: parallel workstreams
For me the most pragmatic way to solve this is in the agent harness layer simply prohibiting commands like git force and others in the settings configuration of your harness of choice with pre tool hooks, its quite easy to setup, obvious ones are prohibiting pushes to main, among others.
Unless someone is building their harness from scratch like you this is a 30sec configuration and you could just save your list of blocked commands with wildcards in a file, and copy paste from one harness to the other.
Agreed. I had to solve this at the harness layer myself. It just makes more sense to me this way. We basically created hooks around these operations and you can configure what happens at these calls.
Disclosure: I'm building AQ (aq.dev) a multiplayer coding harness.
Worktrees are the obvious pick, and I get why. One command, cheap, and if you're the only one driving, then sharing .git is the point rather than a compromise. I started there too.
An agent in a worktree can reach your hooks, your config, another worktree's stash. Probably not a common problem. But when it does happen you're not debugging your code, you're debugging git, and it's not obvious where to even start looking.
The one that actually bothers me is prompt injection. The agent reads an issue, or a dependency's README, or a web page, and what it's told to do is drop a file in the .git it can already write to. Next time you commit, that runs on your machine as you.
Separate thing - worktrees just get annoying to manage. Can't check out the same branch twice, so you're making up branch names to keep git happy. Every one is another directory to keep track of. Then something goes stale and you're back in git worktree prune.
So has any of it got to you? Or do you hit the annoying parts, shrug, and carry on?
Is this an LLM response? If not, take a break, you've assimilated.
I haven’t hit these issues when using worktrees. But what’s a pain is having to compile from scratch every time, and not carrying over gitignored files.
I set up a custom hook in Claude which runs my own worktree creation/cleanup script, which takes care of copying my node_modules into the worktree, my .env (plus doing some edits to the .env to isolate it so it can run in parallel), and stuff like that. Each worktree gets its own docker compose project name so they can run docker stacks in parallel. Works pretty seamlessly.
Same here, over hundreds of worktrees in months of work.
The only problem I ran into was when Codex or Claude Code were configured to create the worktrees nested into the parent repository.
Then grep would yield results from a worktree and the agent would happily start to work in the wrong worktree.
.worktreeinclude is probably part of the solution.
https://code.claude.com/docs/en/worktrees#copy-gitignored-fi...
Please stop writing straw man arguments to sell your product. Worktrees do work as intended for most people. And they work better than your broken homepage.
If you want to properly isolate things, use containers. That's not what worktrees are for.
Agreed, that's my conclusion too. The point isn't that worktrees should be a boundary, it's that a lot of tooling hands agents a worktree and calls it isolation. And the hook thing is why you can't just wrap a worktree in a container to fix it: the worktree's own state lives in the parent's .git, so you'd have to mount that, and then a writable .git/hooks runs on the host. So containers, yes, but around a clone rather than a worktree.