A pool for parallel coding sessions
Git worktrees let several directories share one repository's object database, but managing them manually becomes tedious when each coding agent needs a clean checkout. Treehouse adds a pool. Running treehouse fetches the repository, finds an available slot, resets it to the latest default branch, and opens a subshell there. Exiting returns that worktree for reuse while retaining ignored dependency directories and build caches.
This is a better fit for agent-heavy development than making a full clone per task. Isolation prevents one agent's checkout or untracked files from colliding with another. Shared Git objects save disk, while a warm slot can retain package downloads and compiled artifacts. There is no daemon: commands update a small locked state file and inspect processes when lifecycle operations run.
Treehouse also supports durable leases for automation that cannot keep a subshell alive. A lease has a random identity, optional holder label, timestamp, and JSON output. Conditional return can verify the lease identity before terminating processes or resetting files, which protects against an old cleanup job releasing a later allocation of the same path.
The safety design is unusually explicit
Ordinary prune and destroy operations are dry runs until --yes is supplied. Prune only targets idle, clean worktrees whose HEAD is merged into the default branch. Unreachable remotes, dirty worktrees, leases, running processes, unmerged commits, and missing backing repositories are skipped or reported. Riskier destroy behavior is split across flags for unlanded work, active processes, and leases instead of hidden behind one universal force option.
Recovery is conservative too. State is replaced atomically. If the state file is empty or truncated, Treehouse rebuilds entries from the worktrees on disk and marks all recovered slots as leased because it cannot prove they are safe. An operator must inspect and return each one. Bulk deletion never includes leased worktrees, and an exact path is required to remove one deliberately.
Those choices are excellent. The problem is that safety depends on several inferences being correct: whether an owner is alive, whether another process can write, whether a clean commit has landed, and whether Git ancestry represents the team's merge workflow. Current issues expose failures at those boundaries.
Current reset reports are serious
Issue 79 describes get reclaiming a slot after its owner process ended, seeing a clean working tree, and resetting it even though its committed branch was ahead of the base and had not landed. A matching pull request adds an ahead-of-base check. Until that fix is merged, released, and tested, a clean worktree is not enough evidence that it is disposable. Committed work can be more vulnerable precisely because git status looks safe.
Issues 81 and 82 cover process termination. return can send SIGKILL and proceed to Git commands without waiting for the process to be reaped. Detection also selects processes from a point-in-time scan of current working directories. A writer that changed directories, uses an open file descriptor, or has a child elsewhere can escape the selection while Treehouse resets and cleans the worktree. This is a difficult systems problem, not a cosmetic bug.
Pruning has a merge-model gap as well. Issue 85 notes that squash merges do not preserve the feature branch commits as ancestors of the default branch. A content-equivalent squash can be safely landed while Treehouse continues to classify the old worktree as unmerged. This failure is conservative, so it wastes disk rather than deleting work, but repositories that squash every pull request will accumulate slots or need manual judgment.
Setup includes agent conventions
Treehouse installs through platform scripts, Nix, go install, or source. The CLI defaults to a pool under ~/.treehouse with up to 16 worktrees, and TOML configuration can change the root and pool size. User-level lifecycle hooks run after creation and before destruction. Repository-level hooks are ignored for safety, reducing the chance that untrusted code runs during cleanup. Hook failures are logged and processing continues, so hooks must not be the only protection for valuable state.
Slots use detached HEAD. This avoids branch-name conflicts, but an agent must create a branch or otherwise preserve and land commits before returning the slot. Gitignored environment files may not appear in a fresh worktree. A proposed .worktreeinclude feature addresses that, but users should not assume it exists in v2.1.1.
Large repositories can expose latency. An open issue reports get hanging indefinitely when Git encounters a stale index lock because fetch, checkout, and reset have no timeout or diagnostic. Another asks for step-by-step progress instead of one static setup message. Warm reuse helps after acquisition, but it does not make blocked Git operations disappear.
Health and the decision
Version 2.1.1 shipped on July 31, 2026, and the repository was pushed on August 12. The 35 open issues and pull requests include active work on safety, configuration, worktree seeding, runtime integration, and pool behavior. Development is fast, and the issue quality is notably high. Fast change is also why pinning a release and reading its exact fixes matters.
Treehouse is a smart response to the operational cost of parallel agents, especially its lease identity and conservative deletion interface. Today, however, the open reset paths keep it out of unattended high-value automation. Trial it on repositories with remote backups, inspect status before returns, and preserve branches independently. Once its disposal decisions are proven conservative, the pool model could become the default way to give agents room to work.