Worktrunk
Git worktree plumbing for running several coding agents at once without them wrecking each other's working tree.
The moment you run two coding agents on the same repo they start fighting over the same files. Worktrunk is a thin CLI over git worktree that gives each agent its own checkout, then handles the boring parts: creating, listing, cleaning up, and merging back. It is not an agent framework — it is the filesystem isolation layer that agent frameworks forgot to build. Small enough to read in an afternoon, which matters when it sits under everything you ship.
Best for: Anyone running parallel coding agents against one repository
What to do about it
- Isolates coding agents
- Manages git worktree
- Open-source
What it is
Worktrunk is a command-line tool that uses git worktree to give each coding agent its own isolated checkout of a repository. This prevents agents from interfering with each other's files. It handles tasks like creating, listing, and cleaning up these isolated checkouts, as well as merging changes back into the main repository.
Worktrunk is designed to be a thin layer that provides filesystem isolation for coding agents, rather than an agent framework itself. Its codebase is small and readable, which is important because it sits at the foundation of a deployment stack.
Where it fits in a deployment stack
Tools like Worktrunk are used to manage the interactions between multiple coding agents that need to access the same repository. This is a common problem in deployments where multiple agents need to run concurrently, such as in continuous integration or continuous deployment pipelines.
In a typical deployment, these tools sit between the repository and the agents, providing a layer of isolation and management. They often work alongside other tools that manage the workflow and dependencies between agents.
By providing a way to isolate agents from each other, tools like Worktrunk help prevent conflicts and make it easier to manage complex deployments.
How to evaluate it
To evaluate Worktrunk, you need to consider how it will handle your specific use case. This involves testing its behavior with your agents and repository, as well as examining its code and configuration options. You should look for concrete evidence of its performance and reliability.
- Measure the time it takes to create and switch between isolated checkouts
- Test its ability to handle concurrent access to the same repository by multiple agents
- Inspect the output of the merge process to ensure it handles conflicts correctly
- Examine the codebase to understand its implementation and potential customization options
- Inject failures into the system, such as network errors or disk full conditions, to see how Worktrunk responds
- Verify that Worktrunk correctly cleans up after itself, removing temporary files and checkouts as needed
What to verify before you commit
Before committing to use Worktrunk, you should verify several key aspects of its behavior and implications. This includes checking its licence terms, data handling practices, and operational costs, as well as its potential for lock-in and failure behavior.
- Check the licence terms to ensure they are compatible with your project's requirements
- Verify how Worktrunk handles sensitive data, such as repository credentials or encryption keys
- Estimate the operational costs of running Worktrunk, including any potential performance impacts
- Test Worktrunk's failure behavior, including how it responds to errors and crashes
- Evaluate the potential for lock-in, including the ease of switching to a different tool if needed
- Review the community and support options available for Worktrunk, in case you need help or encounter issues
Where this fits in the FDE path
- FDE career path — the levels, the titles that map to them, and what changes at each step
- Interview guide — what the loop tests beyond coding
- Pay data — 223 postings — midpoint median $231,000, employer-published ranges only
- 922 live FDE roles — pulled daily from employers’ own job boards